Uno dei limiti riscontrati finora dal segmento software di Osterwalder era l'aver ideato un'applicazione solo per iPad. Non perchè non ritenga poco valido il sw, ma perchè questo impediva a utenti non dotati di tale aggeggio di creare i propri canvas...
Un limite che a quanto pare verrà rapidamente eliminato.
Sul blog businessmodelalchemist lo stesso Alex spiega come a breve verrà rilasciata una web app per poter disegnare direttamente da browser i propri business model.
Ottimo. Il canvas è alla versione 0.8, quindi non credo mancherà molto.
Ma di interessante non c'è solo la web app, ma un estensione che questa porta al suo interno: i cosiddetti plug-in al business model canvas stesso!
Di seguito alcune immagini estrapolate proprio dal suo blog (suo di Osterwalder), dove a aprte uno screenshot poco significativo si può ammirare la nuova idea e il concetto che questii plug-in portano in se stessi.
Il tutto ovviamente non poteva non essere corredato da un esempio (Osterwalder adora spiegarsi ad immagini e a concettualizzare il tutto con esempi esplicativi), che tratta lo stesso business che tale applicazione creerà a lui stesso.
Bene. Apsettiamo che venga rilasciata la release definitiva e speriamo non costi molto il suo utilizzo... Almeno per poter provare a giocarci un pò.
Una serie di semplici sketch, idee e riflessioni sul mondo del business, del BPM e del Project Management. Il tutto in modo trasparente poichè non vi sono sponsor o brand di cui siamo fornitori. Business and Process are the main things!
22 febbraio, 2012
17 gennaio, 2012
Il Business Model Canvas durante l'intervista al cliente.
Business Model Canvas: facilità di comunicazione col cliente
Tra i vari problemi che ci si trova spesso a dover affrontare, per chi si occupa di Business Model vi è quello di rappresentare in modo semplice e chiaro il modello su cui poi lavorare, fare considerazioni e valutare le relazioni tra tutti gli elementi che compongono il business stesso.
In un recente lavoro ci siamo imbattuti nell'esigenza di un nostro cliente di aprire una vetrina con dei servizi su internet per i fruitori del noto social network twitter. L'idea si componeva di alcuni semplici servizi, alcuni free altri a pagamento, e si può dire a ragion veduta che ricalcasse il business model di molti altri operatori già attivi sul mercato.
La fase dell'intervista al cliente ha prodotto il classico documento descrittivo e prolisso, da cui poi si estrapolano le esigenze, i bisogni e gli obiettivi verso cui accompagnare il cliente stesso.
A risultare evidente però vi era l'incapacità (in senso buono) del cliente di trattare il business come un elemento unico... sembrava piuttosto che nella sua testa fosse composto da più porzioni che di tanto in tanto dialogavano e interagivano fra loro.
Operare come business analyst comprende tra i suoi doveri quello di addestrare i propri clienti ad utilizzare strumenti a loro meno noti, ma che noi abbiamo collaudato efficaciemente nei passati lavori che ci sono stati commissionati.
Nel caso specifico al di là del business plan che sicuramente aveva prodotto autonomamente, l'ho fatto approciare verso il business model canvas.
Inizialmente la reticenza porta a considerare inutile la rappresentazione grafica del proprio business su un cartellone poichè lo si ritiene "già pronto", una volta che però si è realizzato il primo modello i vantaggi che una simile rappresentazione portano sono indicutibili. Infatti si possono visualizzare le possibili implementazioni future, e se viene abbinato ad una seria analisi di tipo PEST e ad una SWOT... allora è il massimo per poter in seguito estendere e migliorare il business stesso!
Se non altro perchè si ha subito sott'occhio l'intero business nella sua interezza senza la necessità di dover sfogliare avanti e indietro documenti ricchi di parole....
Va detto per onestà che il documento non va in ogni caso tralasciato: ogni strumento va bene per certi lavori ma non per altri, perciò l'intervista descrittiva fissa in modo chiaro (senza elementi sottointesi) i tratti dell'argomento trattato. Purtroppo è solo poco immediata da guardare: il canvas, essendo visuale invece va benissimo per le fasi dove provare a migliorare, ad arricchire, a studiare il business.
Per ovvi motivi qui non inseriremo una versione del modello che abbiamo disegnato per rappresentare il nuovo business del nostro cliente.
Vedere l'idea nel suo complesso ha permesso a noi di consigliare subito un implementazione del servizio che altro non era se non l'interazione di alcune componenti che già vi erano presenti: bastava solo capire che potevano lavorare a braccetto.
In sostanza, l'idea già c'era ma era nascosta: non era stata vista dal cliente, che grazie al canvas ha potuto comprenderne i tratti e valutarne l'efficacia...
A parte il beneficio tratto dal cliente, per noi vi sono stati indubbi miglioramenti: in un unico foglio vediamo proiezioni sulla mole di traffico e utenti dei servizi (stimate dal cliente), vediamo tutti i servizi come strumenti di un unico coltelletto svizzero, e infine quali sono le relazioni che il cliente si prefigge di instaurare coi suoi utenti...
Tra i vari problemi che ci si trova spesso a dover affrontare, per chi si occupa di Business Model vi è quello di rappresentare in modo semplice e chiaro il modello su cui poi lavorare, fare considerazioni e valutare le relazioni tra tutti gli elementi che compongono il business stesso.
In un recente lavoro ci siamo imbattuti nell'esigenza di un nostro cliente di aprire una vetrina con dei servizi su internet per i fruitori del noto social network twitter. L'idea si componeva di alcuni semplici servizi, alcuni free altri a pagamento, e si può dire a ragion veduta che ricalcasse il business model di molti altri operatori già attivi sul mercato.
La fase dell'intervista al cliente ha prodotto il classico documento descrittivo e prolisso, da cui poi si estrapolano le esigenze, i bisogni e gli obiettivi verso cui accompagnare il cliente stesso.
A risultare evidente però vi era l'incapacità (in senso buono) del cliente di trattare il business come un elemento unico... sembrava piuttosto che nella sua testa fosse composto da più porzioni che di tanto in tanto dialogavano e interagivano fra loro.
Operare come business analyst comprende tra i suoi doveri quello di addestrare i propri clienti ad utilizzare strumenti a loro meno noti, ma che noi abbiamo collaudato efficaciemente nei passati lavori che ci sono stati commissionati.
Nel caso specifico al di là del business plan che sicuramente aveva prodotto autonomamente, l'ho fatto approciare verso il business model canvas.
Inizialmente la reticenza porta a considerare inutile la rappresentazione grafica del proprio business su un cartellone poichè lo si ritiene "già pronto", una volta che però si è realizzato il primo modello i vantaggi che una simile rappresentazione portano sono indicutibili. Infatti si possono visualizzare le possibili implementazioni future, e se viene abbinato ad una seria analisi di tipo PEST e ad una SWOT... allora è il massimo per poter in seguito estendere e migliorare il business stesso!
Se non altro perchè si ha subito sott'occhio l'intero business nella sua interezza senza la necessità di dover sfogliare avanti e indietro documenti ricchi di parole....
Va detto per onestà che il documento non va in ogni caso tralasciato: ogni strumento va bene per certi lavori ma non per altri, perciò l'intervista descrittiva fissa in modo chiaro (senza elementi sottointesi) i tratti dell'argomento trattato. Purtroppo è solo poco immediata da guardare: il canvas, essendo visuale invece va benissimo per le fasi dove provare a migliorare, ad arricchire, a studiare il business.
Per ovvi motivi qui non inseriremo una versione del modello che abbiamo disegnato per rappresentare il nuovo business del nostro cliente.
Vedere l'idea nel suo complesso ha permesso a noi di consigliare subito un implementazione del servizio che altro non era se non l'interazione di alcune componenti che già vi erano presenti: bastava solo capire che potevano lavorare a braccetto.
In sostanza, l'idea già c'era ma era nascosta: non era stata vista dal cliente, che grazie al canvas ha potuto comprenderne i tratti e valutarne l'efficacia...
A parte il beneficio tratto dal cliente, per noi vi sono stati indubbi miglioramenti: in un unico foglio vediamo proiezioni sulla mole di traffico e utenti dei servizi (stimate dal cliente), vediamo tutti i servizi come strumenti di un unico coltelletto svizzero, e infine quali sono le relazioni che il cliente si prefigge di instaurare coi suoi utenti...
05 gennaio, 2012
My last tweets ( date descending )
Tip for a good #BPM: help your team to understand the project from a process perspective.
#CIO : It's important you don't attempt #BPM system without mapping process flows.
Work Token is an open source #BPMN 2 engine for #Java programmers who need to develop business processes based on BPMN 2 specifications.
Is convenient to use pre-configured #Business Model in the sw of small businesses?
#7M in #Process: man,machine,material,money, method,message,market. 12manage.com/forum.asp?TB=e…
First days of the #BPM 2012 race! New challenges and new projects: I wish a good start for everyone.
My last tweet for the 2011: I hope Italy will grow in the IT industry. We are at least 10 years behind the rest of Europe ...
Conversazione
@MishaScholte There are also people who do not like public speaking, or those lengthy. Unfortunately, we must also keep in mind these.
@MishaScholte This is a risk. But a social environment includes tools such as chat, webcams, etc ... and we can arrange a live weekly scrum.
@MishaScholte Less time wasted! So less money is spent unnecessarily!!! I hate the time cost of daily scrum :)
@MishaScholte You can learn about the situation in real time. In every moment to ask how to proceed, and if there are hitches.
@MishaScholte ....(like a social network), where voice your concerns, obtain information on job status, ask for help, etc ... like twitter.
@MishaScholte Instead of the daily scrum, every day at work the stakeholders using a collaborative environment ...
@MishaScholte I imagine a Scrum PM framework, complete with ScrumMaster, ProductOwner, Team, all types of meetings except the daily scrum.
@MishaScholte for example think the power of social bpm instead of daily scrum, into a scrum metodology. ;)
@MishaScholte ok, but it's dangerous and expensive 2 stand-up for daily SAL. I prefer social environment: it's possibile real-time check.
IMHO : max 10 people team for a good daily #SCRUM. 5 minutes for 10 people = 50 minute daily SCRUM. What do you think?
Is #PEST analysis sufficient for IT business? Or is it better to use #SLEPT? #STEEPLE(D)?
In a big project the daily #SCRUM it's dangerous. The risk : to put a lot of hour in waste... Too many speakers, to many interview, etc...
TimeMgmt: All activities use the time: the time is limited and shared resource.a project manager must always do time-management. #PMOT
TimeMgmt:time is limited(not infinite),is a good that runs without looking if you spend good,or if we use it according to our plans.#PMOT
Is #MoSCoW analysis (bpmgeek.com/blog/what-mosc…) useful for #SCRUM framework? I think so.
#SWOT: is it simple to do a good analysis? IMHO the tool is simple to use, but not to create. expertprogrammanagement.com/2010/07/swot-a…
#BPM: Modeling o Management? IMHO the folks speak about Modeling using the word Management.....
#BPM: reducing human task increases ROI. It 's always like this? I'm afraid it's true ...
#BPMN Choreography: necessary or is it more helpful to use the lanes? I prefer the lanes for the scalability needed during optimization.
#Bizagi wins 2 Gold Awards for excellence in #BPM:Middle East-Africa Region and the Pacific Rim Region.
#BPMN Conversation: I think they hide a part of the message flow; I find them useful only for broadcast messages.
Thought of the evening. Keeping BPM, Business Rules and Business Intelligence separated. SOA design through Saas? Only costs are benefited?
Business Intelligence and BPM: not only a monitoring process, even a good way to suggest decision for human\hand task.
Business Rules into BPM: typically not full-features. BPM and external BR:full BR functionality. The importance of a SOA architecture of BR.
Swimlane and Pool error: even the experts can make mistakes: Bruce explains it well in brsilver.com/2008/06/11/bpm… via @ bpmswatch.
Common error with swimlanes and pool: bpmsketch.blogspot.com/2011/12/swimla…
#Ovum publishes a shortlist about DecisionMaking: #Appian wins and #WebRatio is absent...4k$:Very expensive because the list is incomplete.
#CIO : It's important you don't attempt #BPM system without mapping process flows.
Work Token is an open source #BPMN 2 engine for #Java programmers who need to develop business processes based on BPMN 2 specifications.
Is convenient to use pre-configured #Business Model in the sw of small businesses?
#7M in #Process: man,machine,material,money, method,message,market. 12manage.com/forum.asp?TB=e…
First days of the #BPM 2012 race! New challenges and new projects: I wish a good start for everyone.
My last tweet for the 2011: I hope Italy will grow in the IT industry. We are at least 10 years behind the rest of Europe ...
Conversazione
@MishaScholte There are also people who do not like public speaking, or those lengthy. Unfortunately, we must also keep in mind these.
@MishaScholte This is a risk. But a social environment includes tools such as chat, webcams, etc ... and we can arrange a live weekly scrum.
@MishaScholte Less time wasted! So less money is spent unnecessarily!!! I hate the time cost of daily scrum :)
@MishaScholte You can learn about the situation in real time. In every moment to ask how to proceed, and if there are hitches.
@MishaScholte ....(like a social network), where voice your concerns, obtain information on job status, ask for help, etc ... like twitter.
@MishaScholte Instead of the daily scrum, every day at work the stakeholders using a collaborative environment ...
@MishaScholte I imagine a Scrum PM framework, complete with ScrumMaster, ProductOwner, Team, all types of meetings except the daily scrum.
@MishaScholte for example think the power of social bpm instead of daily scrum, into a scrum metodology. ;)
@MishaScholte ok, but it's dangerous and expensive 2 stand-up for daily SAL. I prefer social environment: it's possibile real-time check.
IMHO : max 10 people team for a good daily #SCRUM. 5 minutes for 10 people = 50 minute daily SCRUM. What do you think?
Is #PEST analysis sufficient for IT business? Or is it better to use #SLEPT? #STEEPLE(D)?
In a big project the daily #SCRUM it's dangerous. The risk : to put a lot of hour in waste... Too many speakers, to many interview, etc...
TimeMgmt: All activities use the time: the time is limited and shared resource.a project manager must always do time-management. #PMOT
TimeMgmt:time is limited(not infinite),is a good that runs without looking if you spend good,or if we use it according to our plans.#PMOT
Is #MoSCoW analysis (bpmgeek.com/blog/what-mosc…) useful for #SCRUM framework? I think so.
#SWOT: is it simple to do a good analysis? IMHO the tool is simple to use, but not to create. expertprogrammanagement.com/2010/07/swot-a…
#BPM: Modeling o Management? IMHO the folks speak about Modeling using the word Management.....
#BPM: reducing human task increases ROI. It 's always like this? I'm afraid it's true ...
#BPMN Choreography: necessary or is it more helpful to use the lanes? I prefer the lanes for the scalability needed during optimization.
#Bizagi wins 2 Gold Awards for excellence in #BPM:Middle East-Africa Region and the Pacific Rim Region.
#BPMN Conversation: I think they hide a part of the message flow; I find them useful only for broadcast messages.
Thought of the evening. Keeping BPM, Business Rules and Business Intelligence separated. SOA design through Saas? Only costs are benefited?
Business Intelligence and BPM: not only a monitoring process, even a good way to suggest decision for human\hand task.
Business Rules into BPM: typically not full-features. BPM and external BR:full BR functionality. The importance of a SOA architecture of BR.
Swimlane and Pool error: even the experts can make mistakes: Bruce explains it well in brsilver.com/2008/06/11/bpm… via @ bpmswatch.
Common error with swimlanes and pool: bpmsketch.blogspot.com/2011/12/swimla…
#Ovum publishes a shortlist about DecisionMaking: #Appian wins and #WebRatio is absent...4k$:Very expensive because the list is incomplete.
23 dicembre, 2011
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...
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...
20 dicembre, 2011
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) .
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:
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.
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:
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:
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.
Iscriviti a:
Post (Atom)





