Un sincerio augurio di Buon Natale,

e di Buone Feste.

Luca

BPM: Modeling o Management?

A volte si usa parlare di Management mentre si fa Modeling. Quanto si intersecano questi due termini?
Di seguito la mia visione delle cose....


Il ciclo di vita di un Business Process si può rappresentare con un classico loop, che lo suddivide in 4 macrofasi:


Design
Modeling
Execution
Monitoring
Optimization

Molti definiscono questo ciclo come BPM (dove la M sta per Management) lifecycle.
Io non mi identifico tra queste persone, tant'è che ho scritto più in alto solo BP Business Process. Da cosa dipende questa mia posizione?
Vediamolo subito.


Premetto che per me la M di Management non ha il valore che le si da quando si parla di Project Management.
Considerata la mera traduzione di Management, che si traduce con Gestione, mi viene naturale collocare quest'ultimo nelle fasi che vanno dall'esecuzione al monitoraggio (coadiuvato dalla scelta dei dovuti KPI da controllare). Infatti nella nostra lingua la gestione raramente comprende le fasi di analisi, che vengono sempre viste come precedenti al puro "gestire".
Dall'altra parte vi è il Modeling che io identifico solo nelle fasi di Design e di Modeling (per l'appunto!!!). Questa mia puntualizzazione prende vita dall'idea che fare un modello consista nel progettarlo (design) e disegnarne un modello (modeling).


Volontariamente ho saltato l'Ottimizzazione. Perchè? Semplicemente perchè per sapere cosa ottimizzare bisogna averne monitorato le performance, quindi aver GESTITO adeguatamente bene lo screening degli indicatori di performance, nonche' il processo; successivamente , il risultato dell'ottimizzazione servirà per alimentare la re-ingegnerizzazione e nuovamente il design.
Se rappresentiamo l'ottimizzazione come una sorta di TUNING, capiamo meglio come mai questa fase per me è una sorta di ponte che nasce nel Management e termina dentro al Modeling. E' cioe' una fase che partecipa ad entrambe le definizioni di quella benedetta M...


Infatti il tuning inizia migliorando , magari già in produzione, il processo esistente e in un secondo momento trasferendo tali miglioramenti e consolidandoli nella nuova versione del modello.
Perciò , mentre il processo è in esecuzione si verificano e controllano gl'esiti dell'ottimizzazione, poi li si rendono più efficienti integrandoli nel modello in modo definitivo.


Qui però devo essere onesto e avvisare di un possibile problema in cui si rischia di incorrere: execution significa esecuzione e mai e poi mai lo si deve far diventare un "test in produzione". Si deve rilasciare in produzione solo qualcosa di certo!
Alla luce di questo io trovo pericoloso fare un tuning invasivo al processo in produzione. Meglio piccole pezze atte solo a risolvere questioni serie (quindi indispensabili), altrimenti l'ottimizzazione va solo pensata\progettata ma non integrata in ciò che è in esecuzione.


Cosiddette questioni di M...

Sulle acquisizione delle aziende BPM e WebRatio

Da un pò di tempo nel mondo delle suite per il BPM si stanno susseguendo una lunga serie di acquisizioni. Se da una parte tale fermento può essere visto come un buon segno dall\'altra diventa pericoloso scegliere su quale vendor orientarsi. Ma esiste già una possibile cura alla malattia...

Chi opera in settori legati al BPM nell'ultimo periodo ha avuto modo di assistere ad una marea di acquisizioni ad opera di società che sicuramente vedono elevate possibilità di fare business attraverso il BPM stesso (vedi immagine).

Ovviamente la cosa apparentemente non può che dare soddisfazione, poichè si ha così conferma che le proprie scelte sono condivise sempre da più operatori del settore. Il rovescio della medaglia lo si ha per chi consiglia (fa consulenza) o gli spetta l'onere di decidere cosa comprare.
Infatti il limite sta nella consapevolezza che la scelta della suite a cui fare riferimento diventa sempre più ardua. Per i CIO il rischio è quello di appoggiarsi su una piattaforma che rischia nel miglior caso di diventare legacy (anche se con il mantenimento del supporto) ma nel peggior caso di pagare una prematura obsolescenza. Sappiamo che una migrazione comporta sempre lunghi investimenti di tempo e risorse, nonchè elevati periodi di parallelo proporzionali a quanto realmente radicata sia la metodologia BPM nel nostro business. D'altro canto pure il mantenimento all'interno della propria infrastruttura di una suite "datata" (non per vetustà ma per mero business) comporta spese e difficoltà di estensione della stessa: una simile mancanza di scalabilità si paga in molti modi!!!

E' per questo che l'identificare nel panorama BPM un prodotto "platform indipendent", cioè che non richiede una tecnologia specializzata e brandizzata per girare, viene visto dai CIO e dai consulenti come la luce di un faro mentre si è in mezzo al mare. Ovviamente il prodotto è il faro, poi l'ingresso in porto è ad opera dell'azienda che lo utilizza!

Sto parlando di un prodotto tutto italiano ma più diffuso all'estero che nel nostro territorio:WebRatio (www.webratio.com) .

Consideriamo che WebRatio è stato utilizzato proficuamente da Acer per ben 10 anni:

Perchè l'ho definito "platform indipendent"? Perchè WebRatio ha il vantaggio di produrre del codice partendo da diagrammi BPM, il quale può girare su un qualunque application server, nonchè sfruttare infrastrutture generiche e non specializzate. Vi sembra poco? A me no!

Ecco perchè ci siamo decisi di provare il prodotto. Dopo una prima brevissima fase di micro-test interni, a dire il vero molto brevi, abbiamo deciso di passare alla seconda fase: sperimentare WebRatio in un caso di studio reale , parallelamente ad un altro prodotto da noi ben conosciuto (Bizagi), implementando una piccola porzione del progetto (ma pur sempre mappata nel mondo reale) che non verrà rilasciata ma che ci consentirà di fare stime sugli impatti che l'utilizzo di tale prodotto può avere. Parlo ovviamente di impatti sulla curva di apprendimento per utilizzarlo, sul rapporto costo/benefici, sull'efficienza e non per ultimo sul ROI.
Ricordo a tal proposito la famosa piramide che lo stato dell'arte del Project management da come letteratura consolidata:

Di certo a breve vi forniremo i nostri pareri e le nostre considerazioni, magari con un piccolo esempio sonda che avvalori (o almeno accompagni) le nostre affermazioni. Il bello di essere anche noi una società "platform indipendent" ci permette di valutare nuovi prodotti e di poterne parlare onestamente e in modo assolutamente trasparente.

Non vi nascondo che l'averci giochicchiato mi ha già anticipato una sensazione squisitamente proficua.

Swimlane, Pool e processi: errori comuni

Dopo le mie affermazioni sulla mancanza delle collaboration in BPMNComposer mi sono state fatte varie domande sulla reale importanza di una simile assenza, le quali mi hanno fatto ricordare come capiti spesso di vedere abusi ed errori nell'utilizzo delle swimlane e dei pool.



E' possibile utilizzare swimlane al posto di pool o viceversa? NO.
La domanda mi è arrivata in una mail e mi ha rammentato che un primo superficiale approcio a questi due artefatti possa far credere che l'uno sostituisca l'altro.
Invece no. Osserviamo il diagramma qui sotto:

All'interno dello stesso pool vi sono due processi , ma questo va contro le specifiche che l'OMG ha studiato e definito per la BPMN. Se si prova a validare con Bizagi (o altro tool con tale feature) il diagramma infatti si riceverà un errore.
Solo un processo e' consentito, perciò si deve modificare il diagramma come segue:

Se invece andiamo a osservare il diagramma qui sotto , possiamo vedere l'errore contrario: suddividere un unico processo all'interno di una collaboration composta da due pool. Ogni pool DEVE contenere un processo, con relativo start e end event, perciò anche in questo caso la validazione non andrà a buon fine.

Meglio quindi trasformare il diagramma come segue:

Grazie a questi due esempi, parte lo spunto anche per ricordare come tra due pool possano esservi solo delle connection di tipo message flow; ovviamente i message flow non possono essere usati all'interno dello stesso pool dove si devono utilizzare connection di tipo sequence flow. E già che ci siamo ricordiamo anche che un intermediate event non può essere l'inizio per un flusso: questo dovrebbe essere più ovvio visto che il termine intermediate e' esplicativo.

BPM Process Pattern: Incoming Process

L'Incoming Process è un pattern che interviene spesso nei processi dove è richiesta una interazione (collaboration) con il mondo esterno all'azienda.


Il suo utilizzo torna utile quando nella fase di modeling del processo ci troviamo ad affrontare il problema di dover processare un input esterno senza garanzie che questo possa essere realmente utile al nostro core process. Lo spunto per lo sketch mi viene dal blog di Anatoly Belychook, e ne riprendo il caso da lui studiato: la classica "Emissione di Carte di Credito". Rappresentiamolo inizialmente in modo semplificato:

PER I DIAGRAMMI STAVOLTA HO VOLUTO UTILIZZARE INNOVATOR FOR BUSINNES ANALYSTS DI APTERO SOLUTION NELLA PERSONAL EDITION.
INTERESSANTE L'ANIMATION DEL FLOW TRAMITE TOKEN CON LA POSSIBILITÀ DI CREARE PIÙ PATH.

Spieghiamolo un attimo: quando giunge una richiesta di emissione per una nuova carta di credito, tale domanda viene elaborata e se l'emissione viene apprata allora se ne produce una. Il richiedente ha 45gg per presentarsi allo sportello della filiale per ritirarla, altrimenti la carta verrà annullata.

A questo punto proviamo a pensare cosa può creare dei problemi al nostro modello.

Senza dubbio un primo ostacolo possono essere i volumi. Supponiamo che in media i clienti aspettino una decina di giorni e che alla filiale giungano 50 richieste al giorno: il decimo giorno dall'avvio del processo in produzione il nostro impiegato si troverà ad avere in coda 500 carte dove cercare quella da emettere. Un classico problema di stock e di capacità d'emissione per il povero impiegato.

Altro problema, non meno serio riguarda il fatto che l'impiegato non ha la possibilità di eseguire autonomamente il task, ma deve essere il cliente ad arrivare in filiale, il tutto sotto la supervisione dell'impiegato.

Ecco allora che ci vengono inizialmente in aiuto le collaboration e i messaggi (per semplicità consideriamo collassato il pool del cliente):

Non abbiamo però risolto un problema intrinseco ai messaggi in arrivo: il nostro desiderio sarebbe che tra l'utente e l'impiegato si parlasse la stessa lingua, cioè l'utente dicesse tramite ID quale carta ha richiesto. Ovviamente non è concepibile che ciò avvenga, anche perchèl'ID è un concetto puramente legato al nostro DBMS.
Per ovviare a tale serio inconveniente allora ci appelliamo all'Incoming Process Pattern, automatizzando questa fase di associazione cliente-id-carta:

In realtà qui non stiamo considerando molte cose lasciando il tutto solo un esempio (sul suo blog molti si sono lamentati non capendo che lui ha focalizzato l'attenzione sull'Incoming Process più che sulla possibilità di una delivery into production). Ad esempio il caso di un cliente che arriva troppo presto: infatti se così fosse l'impiegato non trova l'ID della carta e manda via il cliente, la carta viene comunque prodotta e passati 45gg verrà cancellata. in questa sede però non ci interessa questo ma solo evidenziare come un messaggio con il mondo esterno possa essere diretto solo se esce dal pool che ci rappresenta, altrimenti se è un messaggio entrante allora è necessario inserire un Incoming Process, cioè un task che processa tale messaggio convertendolo in un linguaggio utile a noi.

In futuro , forse , magari lo estendo un pò così da renderlo più vicino alla realtà.

BPMNComposer: Next generation BPMN tools???

Un nuovo tool cerca di farsi largo tra i tanti presenti nel panorama dei BPMN. Le promesse e la descrizione che ne fanno sono interessanti, ma sarà realmente così? Proviamolo, e scopriamo se ci può far abbandonare altri tool più famosi.

La Business Process Modeling Notation è lo standard globale per la modellazione dei processi, e si preoccupa di far dialogare chi tratta il business con chi si fa parte del puro IT, senza che l'uno debba conoscere i dettagli dell'altro. BPMN2 è una nuova versione di questa specifica, che assicura l'interoperabilità dei modelli progettati e delle presentazioni grafiche.

Nella newsletter di Business Process Incubator ha attirato la mia attenzione il modo in cui presentavano questo: "Next Generation BPMN design tool".
BPMNComposer 1.0 , è la nuova versione del tool di progettazione BPMN:
Dal numero di release direi che più che nuova... è la prima.
Scaricabile dal sito http://www.bpmncomposer.org , si basa sul meta-modello BPMN2 e fornisce - a sentir loro - una nuova capacità di visual design a livello mondiale. 

A chi è rivolto?

La modellazione di processo ( Business Process Modeling ) implica la realizzazione preventiva di un'approfondita analisi di un'organizzazione, e di mio ho la convinzione che questi strumenti rendano il lavoro molto più facile per i consulenti di business, i quali hanno come mission quella di avere una comprensione globale delle competenze di ciascuno stakeholder, compresi quelli IT, per capire come ognuno di essi contribuisce al lavoro da fare (il cosiddetto job-to-be-done, sia customer che internal), e così formalizzare o documentare i processi di business come lo sono oggi e come dovranno essere in futuro.

BPMNComposer, come tutti i tool per la progettazione di processi di business tramite modellazione ( e relativo managment: BPM , infatti sta per Business Process Managment), si rivolge ai consulenti aziendali, ai manager funzionali di specifiche aree (CRM, Acquisti, Risorse Umane, IS, ecc), ed infine ai manager del core business aziendale.

Chi vuole realizzare un modello di processo infatti può utilizzare un tool per il BPM in quanto non è riservato a esperti IT.
Utilizzando un simile software, gli utenti devono poter usufruire della funzione di documentazione come base per la comunicazione con i loro colleghi, specialmente quando presentano il loro lavoro.

BPMNComposer promette tutto questo (del resto come molti altri software già fanno), e onestamente non ho visto questa nuova capacità di visual design.... che non sia già presente in altri software quali ARIS (http://www.ariscommunity.com), Bizagi (http://www.bizagi.com), etc...
Ad onor del vero, nelle versioni PRO, quest'ultimi in più offrono un application server con delle black-box di codice direttamente utilizzabile, in modo da poter implementare al volo il processo software IT, nel caso in cui si stia trattando un processo mappato su questo segmento.

Solo modeling o anche management?

Detto questo, la simpatia per l'uno o l'altro software è soggettiva; sono fermamente convinto che:
Non esiste il tool perfetto per tutto, ma solo il tool più adatto a svolgere un particolare lavoro.
Detto questo risulterebbe difficile avere decine di programmi che svolgono gli stessi compiti, se non altro per non dover imparare ad usarli tutti in modo ottimale.
Quindi la scelta ricade in quello il cui design progettuale più si avvicina alla nostra operatività.
E' però per me condizione sine qua non la capacità di un software non solo di "modellizzare" ma anche di gestire i processi. La M di BPM se non altro sta per Management del Business Process.
Il dettaglio dove spingere questa gestione sta alle esigenze di ognuno.

Le domande che però mi sono balenate si possono riassumere in:
BPMNComposer come si colloca nel mondo BPM? E' solo un tool per il BPMN , cioè la Notazione, o anche per il BPM , cioè il Management?

L'unico modo per scoprirlo è usarlo per un piccolo lavoro che si deve svolgere realmente, in modo da poterlo poi comunque ritrasferire velocemente nel software che abitualmente si usa.
Fare gli HelloWorld è una pratica che va bene solo per capire se i programmi sono installati correttamente!!!!!!

Ho quindi trasferito un semplice processo così come lo implementa attualmente il nostro cliente, però realizzandolo da zero in BPMNComposer. In seguito ho fatto una piccola modifica al processo secondo come dovrà inizialmente svilupparsi la nuova versione dello stesso. Per non sprecare lavoro, ovviamente ho solo eseguito una quota parte della modifica nelal sua interezza , finendo però pur sempre con un prodotto deliverable (come da metodologia SCRUM).
Il processo a cui sono partito:

Lo scopo principale di un BPMN collaboration diagram è di modellizzare le interazione tra i partecipanti. Le interazioni sono rappresentate dai messaggi che attraversono i vari pool, specialmente in un ambiente B2B.

  Impressioni

Da subito si nota l'impossibilità di avere più pool. Anzi, apparentemente mancano le pool e vi sono solo le lane nella palette (la standard anche se di default parte quella dei preferiti), perciò ho dovuto rappresentare stakeholder diversi come facenti parte dello stesso pool.... Già qui meritava di essere chiuso visto che non può ritenersi una mancanza accettabile per tool professionali. Hotel, impiegato e travel agency DEVONO essere tre pool diversi!

La tecnica di disegno è sempre la solita, comune a molti software, ma nell'inserire i task all'interno del sottoprocesso ho avuto alcuni problemi: BPMNComposer ha richiesto il ricaricamento delle versioni precedenti del file appena salvato , pena la perdita delle ultime modifiche.
Dagli eventi (intermedi e non) diventa difficile far partire qualunque flusso o interazione.
Invece del classico gateway con 2 rami di cui uno di default, poichè dal Throw Compensation Intermediate Event non era possibile inserire un connettore di flusso verso il sottoprocesso, mi è toccato usare un gateway complesso.
Dal Book Hotel Room sarebbe stato bello poter inserire una qualche linea che facesse capire come lo start per il Travel Agent aspettasse proprio questa mail.... Stessa cosa dall' End event del Travel Agent mi sarebbe stato utile tracciare una linea di nuovo verso il task Book hotel room. Purtroppo non vi è stato modo: ogni tecnica mi faceva vedere il classico divieto d'accesso che mi impediva di tracciare questi connettori.
Fallisce così lo scopo di poter far parlare un consulente di business con un IT in modo fluido e completo. Di sicuro si sarebbero dovute documentare queste business rule da far implementare dentro al service task, altrimenti l'IT non avrebbe potuto capire che il task doveva implementare un input/output via mail. Ne consegue anche l'impossibilità di utilizzare blackbox-code poichè nessun "processore" potrebbe capire cosa realmente vuole il designer del processo.

A questo punto mi sono fermato e ho lanciato il Validator. Non so come possa aver dato l'OK visto che , connettori a parte, l'evento di compensazione Initiate Cancelation Of Flight And Hotel Room da qualche parte dovrà pur finire... invece rimane pendente (volontariamente lasciato da me) mandando il processo in un limbo.

In conclusione: rimango coi miei vecchi tool e spero che se questo è il nuovo visul-design loro rimangano legacy!

7 Domande per assicurarsi che il MODELLO DI BUSINESS funzioni

I clienti sono gli unici giudici competenti del vostro modello di business. Comunque, anche prima di testare il modello nel mercato, è possibile valutare il suo design con 7 domande che vanno ben oltre l'attenzione tradizionale su prodotti e segmenti di mercato.

Prima le cose basilari. Al fine di valutare il vostro modello di business si dovrebbe delineare su di un canvas il proprio Modello di Business. Ad esempio io sono solito utilizzare il Business Model Canvas (vedi qui sotto) di ALEXANDER OSTERWALDER. 

Valutare le basi
Ogni modello di business ha un prodotto e / o servizio al suo centro, e quest'ultimo si concentra su un esigenza del cliente. Questa viene definito il Value Proposition. Quindi, prima ancora di disegnare il modello di business nella sua totalità, è necessario porsi alcune domande fondamentali su Value Proposition e tipologia di clientela a cui ci si rivolge.
Per prima cosa, il vostro Value Proposition è soddisfare l'esigenza del cliente. Per esempio, se un utilizzatore di un motore di ricerca sta cercando di acquistare le più recenti scarpa da corsa, il successo sarà proporzionale al modo in cui il motore di ricerca lo aiuta a ottenere questo risultato/lavoro.
In secondo luogo, chiedetevi quante persone o aziende fanno già qualcosa di simile. Questo vi darà la dimensione del mercato e vi permetterà di individuare la concorrenza.
In terzo luogo, chiedetevi quanto sia importante questo lavoro per il cliente e se ha in realtà un budget da spendere per esso.
Questi sono i punti base.
Tuttavia, anche i più grandi prodotti stanno avendo un momento critico perchè è sempre più difficile raggiungere un vantaggio competitivo a lungo termine. Per tale ragione è necessario spostare l'attenzione lontano dal puro prodotto / segmento di mercato e orientarsi verso un approccio legato allo studio del proprio modello di business. Qui di seguito sono otto domande per valutare il design del proprio modello di business.

1. Quanto costa l'eventuale migrazione che il clienti deve sostenere?
Il tempo, lo sforzo, o il budget che un cliente deve spendere per passare da un prodotto o fornitore di servizi ad un altro si chiama "switching costs". Più alto è il costo di migrazione, più probabile è un cliente rimanga col vecchio fornitore piuttosto che avvicinarsi ai prodotti o ai servizi di un concorrente.
Un grande esempio di come affrontare il problema dello switching costs è stata l'introduzione dell'iPod nel 2001. Steve Jobs annunciò il suo nuovo prodotto con lo slogan "mille canzoni in tasca". Beh, era più di una semplice innovazione nello storage delle canzoni. E 'stata una strategia basata su un preciso modello di business pensato per arrivare ai clienti e dargli la possibilità di copiare la loro musica in iTunes e iPod, ma che al tempo stesso ha reso più difficile passare ai lettori di musica digitale della concorrenza. In un momento in cui solo le preferenze di brand impedivano alle persone di passare da un lettore all'altro si è trattato di una mossa intelligente e ha posto le basi per il successivo dominio di Apple.

2. E' un modello di business scalabile?
La scalabilità descrive come sia facile espandere un modello di business, senza proporzionalmente dover aumentare i suoi costi base. Naturalmente i modelli di business del software e Web-based sono naturalmente più scalabili di quelli a base di mattoni e malta, ma anche tra i modelli di business digitale ci sono grandi differenze.
Un grande esempio di scalabilità è Facebook. Poche migliaia di sviluppatori che creano Value Proposition per centinaia di milioni di utenti. Solo poche altre aziende nel mondo hanno un rapporto simile di utenti per dipendente. Una società che si è spinta ancora di più al limite è il social gaming Zynga. Con la costruzione di giochi come Farmville o CityVille all'interno di Facebook, il più grande social network del mondo, hanno potuto beneficiare del suo portafolgi utenti senza doversene costruire uno da soli.
Una società che rapidamente ha imparato la lezione per quanto riguarda la scalabilità è stata il peer-to-peer Skype, società di comunicazione, ancora nei suoi primissimi giorni. I rapporti dipendenti/clientela sono diventati rapidamente sbilanciati quando Skype è divenuto diffusissimo e utilizzato da decine di migliaia di utenti al giorno. Ben presto hanno dovuto adattare il loro modello di business per diventare più scalabili.

3. Il vostro modello di business produce ricavi ricorrenti?
I ricavi ricorrenti sono meglio spiegati attraverso un semplice esempio. Quando un giornale guadagna dalle vendite in edicola i ricavi sono transazionali, mentre i ricavi da abbonamento sono ricorrenti. I ricavi ricorrenti hanno il vantaggio di dare una migliore idea preventiva di quanto si guadagnerà in futuro.
Un bell'esempio di ricavi ricorrenti è RedHat, che fornisce software open source e supporto alle imprese sulla base di un abbonamento continuo. In questo modello i clienti non pagano per nuove versioni del software, perché è continuamente aggiornato. Nel mondo del Software as a Service (Saas), questi tipi di abbonamenti sono ormai la norma. Questo contrasta con Microsoft, che vende la maggior parte del suo software sotto forma di licenze per ogni major release.
Tuttavia, c'è un altro aspetto di ricavi ricorrenti, che sono le entrate supplementari generate da un sistema di vendita iniziale. Per esempio, quando si acquista una stampante, si continua a spendere per le cartucce, o quando si acquista una console di gioco, dovrete continuare a spendere per i giochi. Oppure diamo un'occhiata a Apple. Mentre loro continuano a guadagnare la maggior parte dei loro ricavi dalla vendita di hardware, i ricavi ricorrenti da contenuti e applicazioni è in costante crescita.

4. Puoi guadagnare prima di spendere?
Questo va da sé. Quanto più si può guadagnare prima di spendere, meglio è.
Dell è pioniere di questo modello nel settore della produzione informatica hardware. Con l'assemblaggio su ordinativo dopo la vendita sono riusciti a sfuggire al terribile flagello dei costi di magazzino, ancora più gravosi causa svalutazioni nel settore hardware. I risultati hanno mostrato quanto sia potente la capacità di guadagnare prima di spendere.

5. Quanto si ottiene facendo fare parte del lavoro ad altri?
Questo è probabilmente una delle armi meno pubblicizzata nella progettazione del modello di business.
IKEA ci porta ad assemblare i mobili che compriamo da loro. Noi facciamo il lavoro. Loro ci fanno risparmiare denaro, ma loro stessi ne risparmiano. Facebook fa postare le foto, fa creare e fa partecipare a conversazioni, e roba simile. Questo è il valore reale di Facebook: interamente creato dagli utenti; per loro è sufficiente fornire la piattaforma.
La precedentemente menzionata Redhat ha realizzato un altro modello di business intelligente basata sul lavoro di altre persone. Il loro modello di business è interamente costruito in cima ad un software sviluppato dalla comunità open source. Questo ha permesso loro di ridurre sostanzialmente i costi di sviluppo e competere a testa alta con le grandi aziende come Microsoft.
Un modello di business più subdolo in cui gli altri fanno il lavoro è quello praticato dai cosiddetti patent trolls. In questo modello i brevetti sono acquistati con la sola intenzione di richiedere i diritti alle aziende che ne fanno uso, eventualmente citandole in giudizio.

6. Il vostro modello di business fornisce una protezione dalla concorrenza?
Un modello di business è grande se è in grado di fornire a lungo termine la protezione dalla concorrenza e non solo un grande prodotto.
Principale vantaggio competitivo di Apple deriva più dal suo potente modello di business che puramente dai suoi prodotti innovativi. E 'più facile per Samsung, per esempio, copiare l'iPhone che costruire un ecosistema come AppStore di Apple, che si rivolge a sviluppatori e utenti e ospita centinaia di migliaia di applicazioni.

7. Il vostro modello di business cambia le regole del gioco in quanto a costi?
La riduzione dei costi è uno sport molto praticato nel mondo degli affari. Alcuni modelli di business si concentrano sul dare un taglio ai costi creando valore su una struttura di costi completamente diversa.
Skype, per esempio, offre chiamate quasi come una società di telecomunicazioni tradizionali, ma gratuitamente o a un costo molto basso. Possono farlo perché il loro modello di business ha una struttura di costi molto diversa. Infatti, il modello di Skype si basa su l'economia di una società di software, mentre il modello di un fornitore di telecomunicazioni si basa sugli aspetti economici di una società di rete. I primi i costi sono principalmente legati alle persone, mentre i costi di quest'ultimo sono composti da enormi investimenti nel campo delle infrastrutture.
Allo stesso modo, Bharti Airtel, uno dei maggiori fornitori di telefonia mobile al mondo, ha sostanzialmente modificato la sua struttura dei costi per sbarazzarsi di loro tutta la rete e IT. Con l'acquisto di banda di rete (costi variabili) da un consorzio di produttori di apparecchiature di rete (Ericsson e IBM) può ora offrire i prezzi tra i più bassi della telefonia mobile a livello globale.
RedHat, che è stato citato già in precedenza, ha anche costruito il suo modello di business in una struttura basatasopra il lavoro di altre persone.

Come funziona il vostro modello di business?
Nessuno modello di business otterrà pieni voti rispondendo ad ognuno dei quesiti sopra. Qualcuno potrebbe anche avere successo nel mercato senza soddisfarli bene tutti. Tuttavia, ponendosi queste domande e concentrandosi anche solo su alcuni di questi si è molto probabilmente vicini ad ottenere un incremento considerevole sul vantaggio competitivo della vostra azienda nel lungo termine.
Ora tutto quello che dovete fare è testare il vostro modello di business con il vero giudice: il mercato.

Usabilità limitata per le BPMN Lines

Nel normale design secondo i canoni del BPM, le Lines o Swimlanes si dimostrano limitate per alcuni aspetti. Un esempio è meglio di moltissimi parole

Le Lanes (note come swimlanes nel BPMN 1.0) rappresentano gli attori nei processo BPMN.
Regole a cui attenersi:
Le Corsie sono opzionali.Le Corsie possono essere nidificate (gerarchico).La Semantica delle corsie è completamente a discrezione dell'autore del diagramma e possono rappresentare un ruolo, una funzione, o una posizione ...I Sottoprocessi non hanno sub-pool e quindi non possono avere corsie.Le Corsie sono significative solo per le attività degli utenti e per i compiti del servizio.
Anche per i compiti all'utente nella corsia sono essenzialmente un commento all' esecutore reale che è definito dagli attributi del compito dato.

 

Figura 1. Schema BPMN con corsie.
Tuttavia utilizzando le corsie non si metterà in mostra il "percorso più semplice" per il processo, che invece è prezioso dal punto di vista della percezione: 

Figura 2. Diagramma BPMN con un percorso facile.
Inoltre, quando si tratta di grandi processi non c'è spazio per riservare a tutti delle corsie.
C'è una regola generale applicabile a qualsiasi notazione BPMN : il numero di attività a qualsiasi livello grafico non deve superare i 7-9. In caso contrario, il sistema diventa troppo difficile da percepire:

Figura 3. Diagramma "piatto" con un gran numero di attività: è difficile da capire.
Di conseguenza, se il processo comprende un gran numero di compiti, deve essere scomposto in sottoprocessi:

Figura 4. Sottoprocessi aiuto per creare un semplice diagramma di un processo complesso.
Ma questo stile di modellazione non lascia spazio a corsie:
Al livello superiore ci sono solo sottoprocessi mentre le corsie si applicano solo ai compiti utente (regola 5).Il Diagramma con sottoprocesso non consente pool né corsie (regola 4).Più precisamente, la regola 4 si applica solo ai processi integrati; sottoprocessi riutilizzabili possono avere corsie. Ho visto diagrammi sottoprocessi riutilizzabili, che venivano incorporati esclusivamente per essere in grado di rappresentare le corsie. Questo è sicuramente una cattiva pratica: i sottoprocessi devono essere utilizzati per la decomposizione. I Sottoprocessi riutilizzabili introducono ulteriori complessità, perché a differenza dei sottoprocessi incorporati  vengono eseguiti in un contesto di dati separato.
Se non è possibile vivere senza un performer nei diagrammi si può utilizzare l'artefatto BPMN "gruppo":

 
Figura 5. Qui si mostra un gruppo per il performer all'interno del sottoprocesso embedded.
   

Dan Roam con il suo Vivid Thinking rende chiari i MODELLI Di BUSINESS

Il pensiero visivo è fondamentale per la progettazione, per il collaudo, e la costruzione di modelli di business. Dan Roam tratta bene il concetto nel suo libro nuovo di zecca 'Blah Blah Blah:. Che cosa fare quando le parole non funzionano'. E' il libro di riferimento per migliorare nelle conversazioni e nelle riunioni.

Al centro di ogni azienda vi sono due elementi essenziali: un'idea e un piano. Un'idea senza un piano è solo un sogno. Un piano senza un'idea è solo un elenco.
Un business affinchè possa crescere e prosperare, deve avere entrambe le cose.
Un'idea "Vivid" intreccia parole e immagini per creare una visuale + un immagine verbale che possiamo vedere, capire e ricordare. E questo è un ottimo modo per descrivere un business.
Dan Roam è autore del bestseller internazionale "The Back of the Napkin", il più popolare testo sul pensiero visivo, nominato da Fast Company, Business Week e il Times di Londra , il libro numero 1 dell'anno 2011 per la creatività e per l'innovazione .