Progettazione carry over
cosa si intende per progettazione carry over di un processo?
grazie per le eventuali risposte
grazie per le eventuali risposte
Risposte
Dovrebbe essere più o meno il lavoro che andrò a fare dal prossimo settembre.
In senso generale si tratta di prendere un qualcosa di esistente e migliorarlo senza cambiarne la struttura.
Per quanto riguarda i processi, di solito si tratta di lasciare quasi intatta la process map e di lavorare sulle connessioni.
Esempio pratico: introdurre una macro che automatizza un calcolo o una serie di passaggi che in precedenza venivano fatti manualmente.
Un esempio nel settore dei beni (ma non ne sono sicuro) potrebbe essere prendere un modello di automobile, lasciarne invariato il telaio e il motore se questi funzionano bene, e modificare estetica ed interni.
In un certo senso, lo si può definire "rinnovamento", ma dal punto di vista del processo si tratta di identificare gli aspetti vincenti del processo, stabilizzarli, e rendere più efficiente il resto.
Di solito, la scelta tra il rinnovamento di un processo (o un prodotto) è dettata dall'efficienza del processo/prodotto stesso.
Il carry over è conveniente quando il prodotto/processo è all'avanguardia con la tecnologia corrente ma deve essere adattato/ottimizzato in base alle nuove necessità, poichè alcuni aspetti/componenti sono obsoleti.
Se le nuove necessità sono radicalmente diverse, o se buona parte del processo/prodotto è superato, di solito non conviene l'opzione carry over.
In certi casi, il carry over è conveniente poichè la creazione ex-novo di un prodotto/processo è talmente costosa (non solo in termini monetari) da non coprire i vantaggi.
Mentre per i prodotti è "relativamente" semplice, attraverso un'analisi costi benefici, valutare la migliore delle due opzioni, per i processi non è affatto semplice.
Prima di tutto perchè buona parte dei costi/benefici sono difficilmente misurabili, poi perchè è più difficile valutare lo "stato dell'arte".
P.S. complimenti per la firma, è uno dei miei libri preferiti in assoluto.
In senso generale si tratta di prendere un qualcosa di esistente e migliorarlo senza cambiarne la struttura.
Per quanto riguarda i processi, di solito si tratta di lasciare quasi intatta la process map e di lavorare sulle connessioni.
Esempio pratico: introdurre una macro che automatizza un calcolo o una serie di passaggi che in precedenza venivano fatti manualmente.
Un esempio nel settore dei beni (ma non ne sono sicuro) potrebbe essere prendere un modello di automobile, lasciarne invariato il telaio e il motore se questi funzionano bene, e modificare estetica ed interni.
In un certo senso, lo si può definire "rinnovamento", ma dal punto di vista del processo si tratta di identificare gli aspetti vincenti del processo, stabilizzarli, e rendere più efficiente il resto.
Di solito, la scelta tra il rinnovamento di un processo (o un prodotto) è dettata dall'efficienza del processo/prodotto stesso.
Il carry over è conveniente quando il prodotto/processo è all'avanguardia con la tecnologia corrente ma deve essere adattato/ottimizzato in base alle nuove necessità, poichè alcuni aspetti/componenti sono obsoleti.
Se le nuove necessità sono radicalmente diverse, o se buona parte del processo/prodotto è superato, di solito non conviene l'opzione carry over.
In certi casi, il carry over è conveniente poichè la creazione ex-novo di un prodotto/processo è talmente costosa (non solo in termini monetari) da non coprire i vantaggi.
Mentre per i prodotti è "relativamente" semplice, attraverso un'analisi costi benefici, valutare la migliore delle due opzioni, per i processi non è affatto semplice.
Prima di tutto perchè buona parte dei costi/benefici sono difficilmente misurabili, poi perchè è più difficile valutare lo "stato dell'arte".
P.S. complimenti per la firma, è uno dei miei libri preferiti in assoluto.
mmm
sul mio libro ho la seguente definizione:
"la progettazione moderna si concretizza quindi nel selezionare e scegliere i moduli fra quelli disponibili e progettare i legami fra gli stessi moduli, rinunciando al problema del breakdown ossia si ha una progettazione carry over che sta diventando di normale uso per produrre progetti soft in contrasto con i progetti hard(OEM) per realizzare prodotti complessi e in contrasto con gli oggetti o processi o unità aziendali atti a realizzare le aziende a rete"
che mi sembra in effetti combaciare con la tua
mi potresti per favore spiegare la parte rimanente della "definizione", ovvero quella riguardante il breakdown e quella riguardante i progetti hard-soft?
grazie molte
p.s.:puntualizzo che sono uno studente di ingegneria informatica e non di economia e quindui ti prego di non utilizzare un lessico troppo formale XD
p.p.s.:ti ringrazio, nietzche è stato uno degli autori fondamentali della mia tarda adolescenza[decisamente recente e chissà ancora in corso]
sul mio libro ho la seguente definizione:
"la progettazione moderna si concretizza quindi nel selezionare e scegliere i moduli fra quelli disponibili e progettare i legami fra gli stessi moduli, rinunciando al problema del breakdown ossia si ha una progettazione carry over che sta diventando di normale uso per produrre progetti soft in contrasto con i progetti hard(OEM) per realizzare prodotti complessi e in contrasto con gli oggetti o processi o unità aziendali atti a realizzare le aziende a rete"
che mi sembra in effetti combaciare con la tua
mi potresti per favore spiegare la parte rimanente della "definizione", ovvero quella riguardante il breakdown e quella riguardante i progetti hard-soft?
grazie molte
p.s.:puntualizzo che sono uno studente di ingegneria informatica e non di economia e quindui ti prego di non utilizzare un lessico troppo formale XD
p.p.s.:ti ringrazio, nietzche è stato uno degli autori fondamentali della mia tarda adolescenza[decisamente recente e chissà ancora in corso]
Ottimo, il campo software è uno di quelli in cui il carry over è maggiormente utilizzato.
Immagino che tu conosca, o comunque conoscerai sicuramente nel futuro prossimo, SAP.
SAP è un software costruito a moduli e largamente personalizzabile.
Di solito, le aziende acquistano uno o più blocchi del software e poi li customizzano sulla base delle proprie necessità.
Io mi occupo (siamo un team di 50 persone solo per la fase di project management) di implementare una parte dei moduli SAP nella compagnia per cui lavoro; fino a pochi anni fa, questa compagnia sviluppava internamente i software di gestione o ultimamente commissionava a software houses la produzione del software (progetti hard).
Al contrario, ora è stato scelto di acquistare un prodotto sul mercato e adattarlo (progetto soft).
Le differenze sono molte e radicali. In generale, il software prodotto internamente comporta diversi tipi di problemi: il costo di produrre e mantenere il knoh-how internamente (oggi è molto elevato), il costo per il training del personale nuovo (è impossibile trovare sul mercato del lavoro qualcuno con esperienza).
Fino a pochi anni fa, produrre internamente era conveniente, poichè si era in grado di soddisfare le proprie esigenze molto meglio che acquistando all'esterno.
Oggi, tuttavia, le esigenze sono molto maggiori e soddisfarle internamente ha un costo molto elevato, oltre a quelli descritti sopra. Una compagnia di shipping non ha vantaggio ad investire soldi in programmatori e produrre in-house il core software.
Al contrario, acquistando un software modulare, c'è convenienza nell'avere un team di programmatori che facciano la customizzazione dei moduli e un team di process management (o business process owner) che stabilisca cosa il software debba fare e come.
Un po' più semplicemente, supponiamo di dover costruire un mobile per il nostro salotto.
Posso andare da un falegname (o improvvisarmi falegname io stesso), spiegargli nei dettagli cosa voglio e farmi fare il mobile su misura.
Posso andare all'Ikea e farmi un mobile componibile.
Posso andare in un negozio di arredamento e comprare un mobile così com'è.
Supponendo che il mobile sia una tecnologia complicata, quando ha bisogno di essere mantenuto, nel primo caso il falegname (o io stesso) è l'unico in grado di aggiustarlo. Generalmente, questo ha un costo molto elevato al giorno d'oggi, che non sempre copre il vantaggio di avere il mobile fatto "su misura".
Immagino che tu conosca, o comunque conoscerai sicuramente nel futuro prossimo, SAP.
SAP è un software costruito a moduli e largamente personalizzabile.
Di solito, le aziende acquistano uno o più blocchi del software e poi li customizzano sulla base delle proprie necessità.
Io mi occupo (siamo un team di 50 persone solo per la fase di project management) di implementare una parte dei moduli SAP nella compagnia per cui lavoro; fino a pochi anni fa, questa compagnia sviluppava internamente i software di gestione o ultimamente commissionava a software houses la produzione del software (progetti hard).
Al contrario, ora è stato scelto di acquistare un prodotto sul mercato e adattarlo (progetto soft).
Le differenze sono molte e radicali. In generale, il software prodotto internamente comporta diversi tipi di problemi: il costo di produrre e mantenere il knoh-how internamente (oggi è molto elevato), il costo per il training del personale nuovo (è impossibile trovare sul mercato del lavoro qualcuno con esperienza).
Fino a pochi anni fa, produrre internamente era conveniente, poichè si era in grado di soddisfare le proprie esigenze molto meglio che acquistando all'esterno.
Oggi, tuttavia, le esigenze sono molto maggiori e soddisfarle internamente ha un costo molto elevato, oltre a quelli descritti sopra. Una compagnia di shipping non ha vantaggio ad investire soldi in programmatori e produrre in-house il core software.
Al contrario, acquistando un software modulare, c'è convenienza nell'avere un team di programmatori che facciano la customizzazione dei moduli e un team di process management (o business process owner) che stabilisca cosa il software debba fare e come.
Un po' più semplicemente, supponiamo di dover costruire un mobile per il nostro salotto.
Posso andare da un falegname (o improvvisarmi falegname io stesso), spiegargli nei dettagli cosa voglio e farmi fare il mobile su misura.
Posso andare all'Ikea e farmi un mobile componibile.
Posso andare in un negozio di arredamento e comprare un mobile così com'è.
Supponendo che il mobile sia una tecnologia complicata, quando ha bisogno di essere mantenuto, nel primo caso il falegname (o io stesso) è l'unico in grado di aggiustarlo. Generalmente, questo ha un costo molto elevato al giorno d'oggi, che non sempre copre il vantaggio di avere il mobile fatto "su misura".
grazie mille sei stato molto chiaro
si, certamente sap lo conosco anche se a livello generale e non ci ho mai messo le mani sopra
e per quanto riguarda il breakdown in relazione al carry over cosa mi dici?
si, certamente sap lo conosco anche se a livello generale e non ci ho mai messo le mani sopra
e per quanto riguarda il breakdown in relazione al carry over cosa mi dici?
Il breakdown del processo consiste nello scomporre nei diversi moduli il processo stesso.
Nel nostro caso, il processo non è gestito interamente da SAP, ma alcune fasi sono gestite attraverso altri software connessi a SAP attraverso interfacce programmate ad hoc.
Per quello che posso dire, generalmente il breakdown è da attuarsi solo quando la soluzione esistente non è in grado di soddisfare i requisiti e talvolta (come nel nostro caso) può succedere.
Diciamo che SAP è un software con molte possibilità di customizzazione, pertanto si acquistano i moduli necessari e poi si provvede alla programmazione degli stessi (carry over).
Lavorando solo su moduli dello stesso prodotto (SAP nel caso) si minimizza il breakdown, riducendo i costi e i rischi dovuti ai passaggi intermedi, che talvolta possono creare problemi.
Nel nostro caso, buona parte dei problemi sono proprio dovuti alla comunicazione tra SAP e i legacy system; per questo motivo si cerca di limitare il più possibile il breakdown.
Insomma, è un po' come arredare una stanza usando mobili provenienti da diverse soluzioni: uno è bianco, uno è rosso, uno in plastica, uno in legno.
Si opta per questa soluzione solo se non si può fare altrimenti (in teoria).
Nel nostro caso, il processo non è gestito interamente da SAP, ma alcune fasi sono gestite attraverso altri software connessi a SAP attraverso interfacce programmate ad hoc.
Per quello che posso dire, generalmente il breakdown è da attuarsi solo quando la soluzione esistente non è in grado di soddisfare i requisiti e talvolta (come nel nostro caso) può succedere.
Diciamo che SAP è un software con molte possibilità di customizzazione, pertanto si acquistano i moduli necessari e poi si provvede alla programmazione degli stessi (carry over).
Lavorando solo su moduli dello stesso prodotto (SAP nel caso) si minimizza il breakdown, riducendo i costi e i rischi dovuti ai passaggi intermedi, che talvolta possono creare problemi.
Nel nostro caso, buona parte dei problemi sono proprio dovuti alla comunicazione tra SAP e i legacy system; per questo motivo si cerca di limitare il più possibile il breakdown.
Insomma, è un po' come arredare una stanza usando mobili provenienti da diverse soluzioni: uno è bianco, uno è rosso, uno in plastica, uno in legno.
Si opta per questa soluzione solo se non si può fare altrimenti (in teoria).
ok chiarissimo grazie mille
per curiosità, in cosa sei laureato?
per curiosità, in cosa sei laureato?
Sono laureato in economia marittima e dei trasporti.
Di solito, al livello uno, è giusto che ci siano degli economisti.
Al giorno d'oggi, le singole competenze non sono più sufficienti; riuscire ad avere delle cross competencies è un vantaggio notevole.
Di solito, al livello uno, è giusto che ci siano degli economisti.
Al giorno d'oggi, le singole competenze non sono più sufficienti; riuscire ad avere delle cross competencies è un vantaggio notevole.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo