Erp

[mydb]

Salve a tutti.

Ho sempre progettato database considerando e basandomi sui requisiti utente.

Sto approcciando ora al mondo dell'erp (enterprise resource planning)

C'e qualcuno tra di voi che ci lavora o ci ha lavorato che puo descrivermi come si approcciano i progetti in quella visione e come si lavora in generale o altre notizie che ritenete utili?

Grazie a tutti

[franzauker2.0]

Originariamente inviato da mydb
Salve a tutti.

Ho sempre progettato database considerando e basandomi sui requisiti utente.

Sto approcciando ora al mondo dell'erp (enterprise resource planning)

C'e qualcuno tra di voi che ci lavora o ci ha lavorato che puo descrivermi come si approcciano i progetti in quella visione e come si lavora in generale o altre notizie che ritenete utili?

Grazie a tutti

Hai chiesto poco...
Ognuno ha il suo approccio specifico, in particolare se si sviluppa un progetto che dal lato amministrativo-contabile viene completato con la produzione, oppure viceversa.

Spesso (per la maggior parte degli ERP nazionali) la direzione è proprio quella: amministrazione => produzione, sia perchè le aziende con produzione sono poche, rispetto alla platea dei clienti potenziali, sia perchè le produzioni sono assolutamente diversificate, anche all'interno delle medesime categorie produttive.

Se ci riferiamo specificamente agli approcci nella progettazione dei database ci sono, anche qui, notevoli differenze tra chi predilige normalizzazioni spinte, e chi invece de-normalizza ove possibile.

Tipicamente i primi hanno prestazioni bassissime, ridicole in certi casi.

Poi che dire... se vuoi dettagli più precisi prova a circoscrivere la richiesta

[mydb]

ciao franzauker2.0 inanzitutto ti ringrazio per la risposta.

Purtroppo Non so fornirti ulteriori dettagli proprio perche' ci sto appena approcciando.

Una cosa che mi viene da chiedere a te che sembri esperto da come parli e':

che differenze ci sono (ammesso che ve ne siano) tra progetto di un db "classico" e un progetto di db per erp??

Grazie.

[mydb]

ovviamente la domanda :

che differenze ci sono (ammesso che ve ne siano) tra progetto di un db "classico" e un progetto di db per erp??

e' valida per ogni forumista che ne sa qualcosa

grazie a tutti

[franzauker2.0]

Nessuno, ovviamente.
ERP non è magia, unicamente la fusione delle 3 aree principali (più quelle minori) delle aziende.
La differenza essenzialmente è nel predisporre una (auspicabilmente) semplice integrazione tra le varie aree, soprattutto di quella, come accennato, di produzione, che ha spesso caratteristiche specifiche.
Poi c'è tutto il problema, ad esempio, di un configuratore tecnico commerciale (nel caso di produzioni ad elevata variabilità) dove (sempre in teoria) le scelte non vanno fatte per la singola sottosezione, quanto per il progetto complessivamente inteso.

Siccome è normale, inoltre, avere molte centinaia di tabelle, parecchie delle quali di semplici anagrafiche, la discussione tra gli approcci diciamo così scolastici e quelli più pragmatici è sempre aperta.

Va inoltre precisato che, tipicamente, NON si assiste alla nascita di un ERP dal niente, quanto un processo di accrescimento progressivo sulla base di prodotti non omogenei, anzi talvolta addirittura acquistati da terzi (!!) tipo schedulatori a capacità finita, piuttosto che dipartimentali di magazzino etc.

E, a complicare ancor più la situazione, quasi sempre chi si occupa di progetti così grandi non conosce affatto l'intero, ma solo parti.
Puoi avere tizio che sa tutto della riclassificazione dei bilanci, ma non ha idea di cosa sia un ciclo di lavorazione e così via.

Per aziende informatiche piccole (tipo quelle italiane) ciò porta ad avere un numero davvero ristretto di persone che conoscono davvero il prodotto: talvolta 1, 2 o 3 e basta.
Nelle realtà più piccole sono,tipicamente, il proprietario \ i fondatori; in quelle medie (100-300 dipendenti) non molti di più, perchè il turn over è forte e così via.

[mydb]

grazie mille.

Davvero molto interessante. Piano piano studiero l'approccio.

Per il momento non mi occupero' in prima persona del modello erp ma se ne occupera il project manager io sono se vogliamo il "vice" .

Pero' mi interessava conoscere l'argomento. TI ringrazio molto.

Toglimi una piccola curiosita', la tua conoscenza sull'argomento e' dovuta al tuo lavoro come magari project manager o cultura personale??

[franzauker2.0]

Originariamente inviato da mydb
Toglimi una piccola curiosita', la tua conoscenza sull'argomento e' dovuta al tuo lavoro come magari project manager o cultura personale??

Mi occupo di stabilire come era bene progettare gli ERP, come dovevano essere realizzati, se raggiungono effettivamente quanto promesso, e nel caso quali danni hanno provocato, quanto costa "ripararli", come vanno effettuate le "riparazioni", cosa fare perchè non si ripeta.
Oltre a progettarli, scriverli e venderli in prima persona da una 20ina di anni.
In altre parole tiro a indovinare

Visto che ci sono segnalo una particolarità che, invero, c'è o meglio frequentemente va prevista.
L'indicazione per ogni riga del polo amministrativo (l'azienda, per capirci), l'utente creatore, data e ora creazione, utente ultima modifica, data e ora ultima modifica.
Oltre, molto spesso, a registri di attività particolari (es. modifiche fatture stampante in via definitiva, cancellazione, alterazione dei numeratori etc).
Più l'azienda è grande, e tipicamente un ERP "vero" si monta diciamo da un minimo di 30-50 dipendenti in su, più occorre prevedere l'utilizzo multiaziendale e l'individuazione delle varie attività svolte.

Ad esempio sognati di fare un "cancella fattura" senza registrare chi, come e perchè ciò è stato fatto, e magari tenerne pure una versione di backup (* nota in quest'ultimo caso va considerata la possibilità che le aziende NON vogliano lo storico delle modifiche, ad esempio... per... il nero... quindi va parametrato il livello di log che si vuole mantenere)

Altre cose, ma ce ne sono tantissime, è la previsione perentoria di campi e tabelle non vuote, o la capacità del programma di funzionare anche senza, e nel caso autocompilare quelle minime.

Ce ne sono tante, tipo anagrafiche, banche, piano dei conti, strutture articoli, distinte base etc che, in fase di avvio, possono richiedere anche settimane (per SAP anche mesi) se non esiste una resilienza del programma o, di converso, un vero e proprio "inizializzatore".

Capita infatti di scrivere un programma solo per inizializzare le tabelle principali (una sorta di superwizardone gigantesco), perchè spesso è facile che i consulenti applicativi dimentichino che il flag superpippo va posto a "vero" quando hai una banca che ha un metodo strano per notificare i movimenti delle carte di credito etc.

Eppoi ci sono due temi giganteschi
1) le personalizzazioni (o verticalizzazioni)
2) l'affiancamento per l'avvio
- gli aspetti commerciali neppure li introduco
- i bs o canoni di assistenza e manutenzione etc.

Diciamo che è facile che le licenze software risultino una frazione anche piccola di un progetto complesso, ad esempio 50.000 euro vs 500.000 complessivi tra analisi, implementazioni e così via.

[bomberdini]

si immagino che le sfaccettature da tenere in considerazione siano davvero molte.

[bomberdini]

ps interessante questo post

[mydb]

grazie mille a tutti