House of bpm
qual'è precisamente la funzione del software house of bpm di sap?
grazie delle eventuali risposte
grazie delle eventuali risposte
Risposte
La che del cosa? 
Ehm, sarebbe il mio lavoro.
Tuttavia, si tratta di un qualcosa di enorme da spiegare su un forum.
ARIS è solo un software di rappresentazione, che peraltro usiamo anche noi, ma la cosa fondamentale non è il software in sè quanto il lavoro che si fa con ARIS, che poi è il cuore del BPM.
Sono stati scritti dei libri interi su questa roba qua. In pratica si tratta della gestione del processo (qualunque esso sia) e della sua ottimizzazione.
Si parte dall'analisi dei requisiti, si trova una "soluzione", ovvero il processo che si intende mettere in atto, si costruisce un pilota, si testa, e poi si aggiungono varie parti.
Dopo l'implementazione, si monitorano i risultati e si lavora sulle parti del processo per cui i risultati non sono soddisfacenti.
Questo in poche parole.
Alle spalle, c'è un lavoro enorme che comporta competenze molto diverse e specifiche, che difficilmente possono essere gestite da un solo team.
Se hai qualche curiosità specifica, chiedi pure.
Tuttavia, si tratta di un qualcosa di enorme da spiegare su un forum.
ARIS è solo un software di rappresentazione, che peraltro usiamo anche noi, ma la cosa fondamentale non è il software in sè quanto il lavoro che si fa con ARIS, che poi è il cuore del BPM.
Sono stati scritti dei libri interi su questa roba qua. In pratica si tratta della gestione del processo (qualunque esso sia) e della sua ottimizzazione.
Si parte dall'analisi dei requisiti, si trova una "soluzione", ovvero il processo che si intende mettere in atto, si costruisce un pilota, si testa, e poi si aggiungono varie parti.
Dopo l'implementazione, si monitorano i risultati e si lavora sulle parti del processo per cui i risultati non sono soddisfacenti.
Questo in poche parole.
Alle spalle, c'è un lavoro enorme che comporta competenze molto diverse e specifiche, che difficilmente possono essere gestite da un solo team.
Se hai qualche curiosità specifica, chiedi pure.
si, ok mi rendo conto della vastità dell'argomento[anche perchè in minima parte lo sto affrontando XD]
ma quello che mi chiedo è in particolare il senso dell'house of bpm..."so" cos'è aris e "so" cos'è il bpm ma non riesco a capire cosa sia quest'h.o.bpm
in particolare ci è stata accennata a lezione, se hai voglia di vedere in che termini ti passo il link
http://www2.ing.unipi.it/~a003248/EOA/Processi/
si trova nel pacchetto di slide evoluzione del bpm in particolare le slide dalla 10 alla 16
ma quello che mi chiedo è in particolare il senso dell'house of bpm..."so" cos'è aris e "so" cos'è il bpm ma non riesco a capire cosa sia quest'h.o.bpm
in particolare ci è stata accennata a lezione, se hai voglia di vedere in che termini ti passo il link
http://www2.ing.unipi.it/~a003248/EOA/Processi/
si trova nel pacchetto di slide evoluzione del bpm in particolare le slide dalla 10 alla 16
La house of BPM è il cuore del process management.
Trovo che la presentazione sia fatta piuttosto bene; naturalmente, non può essere sufficiente, su questa roba qua, come ho già detto, sono stati scritti dei libri interi (e altri se ne dovranno scrivere).
Partendo dall'immagine che hai postato prima, che trovo molto chiara, cerco di spiegare.
Il livello più alto è composto da specialisti del business, che definiscono la strategia e i requirements (questo è grosso modo il mio lavoro).
A questo livello, si definiscono i requisiti del processo, includendo una mappatura, ovvero quello che si vuole nel dettaglio, da non confondersi con i requisiti di scopo affrontati nella ARIS house, che sono più generici (diciamo a livello 4, per parlare con la terminologia ARIS). Per farla breve, a questo livello si fanno i PDD.
Il simbolo del livello è l'occhio, ad indicare che questa è la parte "visuale" in cui si "osserva" il prodotto. All'inizio del progetto, si disegna quello che si vuole. Il nostro capo definì quella fase (infelicemente) "Christmas eve".
Al secondo livello, si prendono i PDD e si cerca la soluzione a livello pratico, ovvero come mettere in pratica i requirements aggiustando quello che si ha. Questa è la fase più importante nel carry over, poichè è proprio qui che si cerca di soddisfare il requisito esterno modificando (il meno possibile) ciò che si ha a disposizione. Qua si fa la progettazione delle modifiche al software, non a livello di codice, ma a livello di struttura e di processo (un quasi pseudo-codice).
Il simbolo del livello è la testa, poichè qua si trovano le soluzioni pratiche. Guardando certe soluzioni che ci vengono propinate, talvolta sono spinto a pensare che il culo sarebbe molto più adatto come simbolo...
Al terzo livello, si scrive effettivamente il codice e si mette in atto la soluzione. Questo è il lato operativo e c'è poco da dire. Il simbolo è la mano (anche se talvolta penso che il piede sarebbe più adatto). In questa fase, di solito, vengono eseguiti il JIT e il RT.
Dopo di che, si torna al livello due, dove si osserva che il lavoro fatto corrisponda effettivamente alla soluzione prevista. In questa fase si fa (si dovrebbe fare) il SIT.
Tornando al livello uno, si porta il prodotto ai business owner che, con l'aiuto dei business expert, valutano la coerenza tra il risultato e il requirement.
In questa fase, si fa il UAT.
Vale la pena spendere due parole anche sulle interazioni tra i livelli.
Il livello uno e due comunicano perchè talvolta una leggera modifica dei requirement potrebbe comportare una soluzione molto più semplice, e può succedere che alcuni dei requirements non siano così fondamentali.
Il livello due e tre comunicano perchè può succedere che la soluzione non sia tecnicamente possibile. SAP, ad esempio, ha alcune parti "hard coded" che rendono la vita un po' più complicata.
Dopo di che, livello due e tre comunicano per trovare gli adattamenti alla soluzione quando vengono sollevati (di solito a tonnellate) dei TPR durante il SIT.
La comunicazione torna dunque tra il livello uno e due quando si tratta di validare il risultato (che di solito è qualcosa di molto diverso da quello che ci si aspettava).
Ho una vignetta divertente sulla cosa, appena la trovo, la posto.
Trovo che la presentazione sia fatta piuttosto bene; naturalmente, non può essere sufficiente, su questa roba qua, come ho già detto, sono stati scritti dei libri interi (e altri se ne dovranno scrivere).
Partendo dall'immagine che hai postato prima, che trovo molto chiara, cerco di spiegare.
Il livello più alto è composto da specialisti del business, che definiscono la strategia e i requirements (questo è grosso modo il mio lavoro).
A questo livello, si definiscono i requisiti del processo, includendo una mappatura, ovvero quello che si vuole nel dettaglio, da non confondersi con i requisiti di scopo affrontati nella ARIS house, che sono più generici (diciamo a livello 4, per parlare con la terminologia ARIS). Per farla breve, a questo livello si fanno i PDD.
Il simbolo del livello è l'occhio, ad indicare che questa è la parte "visuale" in cui si "osserva" il prodotto. All'inizio del progetto, si disegna quello che si vuole. Il nostro capo definì quella fase (infelicemente) "Christmas eve".
Al secondo livello, si prendono i PDD e si cerca la soluzione a livello pratico, ovvero come mettere in pratica i requirements aggiustando quello che si ha. Questa è la fase più importante nel carry over, poichè è proprio qui che si cerca di soddisfare il requisito esterno modificando (il meno possibile) ciò che si ha a disposizione. Qua si fa la progettazione delle modifiche al software, non a livello di codice, ma a livello di struttura e di processo (un quasi pseudo-codice).
Il simbolo del livello è la testa, poichè qua si trovano le soluzioni pratiche. Guardando certe soluzioni che ci vengono propinate, talvolta sono spinto a pensare che il culo sarebbe molto più adatto come simbolo...
Al terzo livello, si scrive effettivamente il codice e si mette in atto la soluzione. Questo è il lato operativo e c'è poco da dire. Il simbolo è la mano (anche se talvolta penso che il piede sarebbe più adatto). In questa fase, di solito, vengono eseguiti il JIT e il RT.
Dopo di che, si torna al livello due, dove si osserva che il lavoro fatto corrisponda effettivamente alla soluzione prevista. In questa fase si fa (si dovrebbe fare) il SIT.
Tornando al livello uno, si porta il prodotto ai business owner che, con l'aiuto dei business expert, valutano la coerenza tra il risultato e il requirement.
In questa fase, si fa il UAT.
Vale la pena spendere due parole anche sulle interazioni tra i livelli.
Il livello uno e due comunicano perchè talvolta una leggera modifica dei requirement potrebbe comportare una soluzione molto più semplice, e può succedere che alcuni dei requirements non siano così fondamentali.
Il livello due e tre comunicano perchè può succedere che la soluzione non sia tecnicamente possibile. SAP, ad esempio, ha alcune parti "hard coded" che rendono la vita un po' più complicata.
Dopo di che, livello due e tre comunicano per trovare gli adattamenti alla soluzione quando vengono sollevati (di solito a tonnellate) dei TPR durante il SIT.
La comunicazione torna dunque tra il livello uno e due quando si tratta di validare il risultato (che di solito è qualcosa di molto diverso da quello che ci si aspettava).
Ho una vignetta divertente sulla cosa, appena la trovo, la posto.
Eccola.
quindi si tratta di uno schema concettuale di come le cose devono essere gestite se non ho capito male...perchè dalle slide del mio professore non si riusciva a capire bene se si trattasse di un software od altro.
per quanto riguarda invece la aris house che si trova subito prima nel pacchetto delle slide cosa mi puoi dire?
nel senso: si tratta di uno schema concettuale di "come si dovrebbe agire" o di un software?
p.s.:LOL, allora anche gli economisti(o economi non so come si dica XD) fanno battute nerd XD
per quanto riguarda invece la aris house che si trova subito prima nel pacchetto delle slide cosa mi puoi dire?
nel senso: si tratta di uno schema concettuale di "come si dovrebbe agire" o di un software?
p.s.:LOL, allora anche gli economisti(o economi non so come si dica XD) fanno battute nerd XD
Sulla prima parte di ARIS, spenderò un po' di tempo ugualmente.
In questi giorni non ho molto tempo per rispondere perchè sto cambiando casa e devo fare tutti i lavori nella casa nuova.
Dovrei finire entro sabato.
In questi giorni non ho molto tempo per rispondere perchè sto cambiando casa e devo fare tutti i lavori nella casa nuova.
Dovrei finire entro sabato.
Di per sè, la prima parte di ARIS è poco più di un software che consente di fare process maps.
Prima di intraprendere una progettazione vera e propria, si fa una serie di mappe concettuali in cui si parte dal livello più alto del processo (qualcosa quasi del tipo acquisto-produco-vendo) fino al livello più basso (mi pare sia chiamato livello 5 in ARIS) in cui si descrivono le SOP.
Naturalmente, il livello 5 è impensabile prima della fase di progettazione. A ben vedere, anche il livello 4 crea già qualche problema, soprattutto perchè si rischia di creare rigidità nelle fasi successive. In alcuni casi, questa rigidità è necessaria, in altri è dannosa.
In questo senso, ARIS è un software che aiuta a seguire una certa struttura nel processo.
Prima di intraprendere una progettazione vera e propria, si fa una serie di mappe concettuali in cui si parte dal livello più alto del processo (qualcosa quasi del tipo acquisto-produco-vendo) fino al livello più basso (mi pare sia chiamato livello 5 in ARIS) in cui si descrivono le SOP.
Naturalmente, il livello 5 è impensabile prima della fase di progettazione. A ben vedere, anche il livello 4 crea già qualche problema, soprattutto perchè si rischia di creare rigidità nelle fasi successive. In alcuni casi, questa rigidità è necessaria, in altri è dannosa.
In questo senso, ARIS è un software che aiuta a seguire una certa struttura nel processo.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo
