ERP con Plone..

12 febbraio 2010

Fabrizio ha lanciato un ottimo stimolo, anche se ancora da sviluppare: quando usare Plone per risolvere alcune delle funzioni tipiche di un ERP (http://redomino.com/it/labs/blog/fabrizio-reale/plone-erp).

In merito ho qualcosa da dire, ma voglio farlo con calma, non in questo post (tanto per capirci, da tempo ho “in canna” di parlare di Case Management con Plone, che copre una parte delle proposte di Fabrizio… piano piano ;)).

Piuttosto volevo rispondere organicamente al commento di Andrea, che quoto nella sua chiosa:

secondo te Plone può essere usato, oltre alla gestione documentale, anche per la gestione delle attività come emissione fatture, ddt, ordini etc… ?

Quello che io intendo e avere un sistema in cui collaboro alla vita aziendale (CMS puro e semplice), gestisco i servizi con i clienti (trouble ticket), amministro i miei servizi, fatturo ai clienti, emetto ordini ai fornitori, ddt per i tecnici.

Non capisco perché queste operazioni vengano definite da molti sviluppatori Plone come troppo complesse per un CMS, e parlo anche a livello di costi di sviluppo. Scusa ma con PHP queste cose si fanno da anni, a costi decenti e molto inferiori rispetto a soluzioni Plone o JSP.

Be’, ho due cose da dire a riguardo.


La prima, spicciola: se “queste cose si fanno da anni in PHP a costi decenti e molto inferiori rispetto a soluzioni Plone o JSP”, ben vengano! Perchè Andrea sente la mancanza di qualcosa che PHP non sia? Forse le soluzioni “che si trovano” rispetto a quelle che, ancora oggi, “non si trovano” (non tanto in Plone, quanto in Java) fanno una differenza sostanziale che in parte giustifica i costi lamentati? 🙂

La seconda: credo di far parte di quegli sviluppatori Plone (o meglio, integratori Plone) che definiscono “queste cose” troppo complesse per un CMS, o troppo costose da realizzare. Quindi cerco di ribadire il concetto in modo semplice, e spero di non essere frainteso.

Premessa: quando si fanno certe considerazioni, un integratore Plone parla di Plone, e non della famiglia dei CMS in generale, in cui si fanno entrare cose diverse come Worpress, Joomla! e Alfresco.

Veniamo alla mia spiegazione a riguardo, sottolineando come Plone disponga di strumenti molto avanzati, stabili e collaudatissimi da molti anni per poter risolvere una serie di problematiche tipiche dei Web CMS (categoria di cui Plone fa parte a pieno titolo). Ne cito qualcuno:

  • Archetypes per creare i modelli informativi dei contenuti e tutto quel che serve a farli funzionare (storage, indicizzazione, interfacce utente di base, etc.) dichiarando un semplice schema di attributi!
  • Workflow Documentale per gestire flussi di lavoro collaborativi sui documenti descritti da diagrammi di stato molto facili da personalizzare
  • Indicizzazione Interna per interrogare la propria base informativa comunque sia necessario, cercando anche all’interno dei file PDF, Office, etc.
  • Versioning Documentale per disporre delle passate versioni dei documenti ed eventualmente ripristinarle
  • Zope Page Template, registri CSS e JS, viewlet e portlet per costruire le proprie interfacce utente web in maniera rapida e flessibile
  • etc. etc. le feature di Plone non si esauriscono certo qui!

Per quanto riguarda l’ambiente in cui Plone è implementato, si tratta di Zope, un application server molto verticale sulle sue funzionalità e dotato di:

  • un ORB orientato ad internet (il Publisher, molto robusto e longevo)
  • un DB a oggetti integrato e trasparente (NoSQL ante-litteram e anche di più),
  • un potente modello di sicurezza che permette di usare il DB a oggetti come fosse un filesystem agli steroidi

Zope [ndr. Zope 2!!, da non confondere con Zope 3, che di Zope 2 fa parte, ma con cui viene costruito anche Grok, BlueBream e a cui si appoggia BFG] è perfetto per quel che ci si può fare, ma difficile da trasformare in qualcosa di diverso (se i framework negli ultimi anni hanno riscosso tutto questo successo un motivo valido ci sarà..).

Alla fine di questa specie di sviolinata cerco di spiegare il perchè “certe cose” sono costose da fare in Plone:

se il modello complessivo che Plone rappresenta non è piuttosto vicino all’implementazione ideata per risolvere il proprio problema, con o senza contenuti web di mezzo, la fatica che si fa a “combattere” il framework è maggiore di quella che piuttosto si farebbe a partire senza quell’aiuto.

Allora chiedo: dovendo andare ad una cerimonia, faccio prima a vestirmi in un negozio di abbigliamento o a rivolgermi ad un sarto?

e chiedo ancora: dovendo procurarmi un costume da bagno, faccio prima a riadattare dei pantaloni comprati nel negozio di prima, a rivolgermi ad un sarto o piuttosto a cercare in un negozio di articoli sportivi?

La cosa difficile da far intuire a chi non la vede già da sé è come sia possibile che per fare certe cose molto complesse Plone ci metta “così poco”, mentre per farne altre, apparentemente semplici e alla portata di “tutti”, in Plone costi una fortuna.

Il motivo dovrebbe essere evidente se si considera che tutti gli strumenti citati sopra sono molto specializzati per erogare, ciascuno al suo livello, l’esperienza che Plone fa apparire semplice da controllare, ma che tanto semplice non è!

Non è semplice, come dimostra il fatto che dopo tutti questi anni io ancora sto cercando (seriamente!) un’alternativa equivalente e più all’avanguardia di Plone.

E non è semplice anche perchè Plone ingloba un numero spaventoso di giorni uomo, seppure forse ben camuffati dall’apparente semplicità di quello che vediamo funzionare, e molto bene, tutti i giorni come un orologio svizzero.

Annunci

2 Risposte to “ERP con Plone..”

  1. Matteo Sorba Says:

    Amen.

    La realtà è che più costruiamo strumenti per semplificare il lavoro e più creiamo digital divide.

    Capire come aggiungere complessità in uno strumento per rendere più semplice il lavoro di qualcuno, significa che si hanno ben chiare le difficoltà di quello specifico lavoro.

    Non credo si possa capire la direzione di uno strumento se non se ne vedono nemmeno gli sforzi fatti per migliorarlo.
    Si rischierebbe di confondere, appunto, strumenti nati per esigenze diverse solo perchè si “assomigliano”.

    Per capire come si lavora bene con una ruspa (e gli sforzi fatti per migliorarla) devo provare a scavare una fossa con una pala.
    O, perlomeno, avere l’elasticità mentale di immedesimarmi nel gesto.

    L’idea di usare una ruspa per tutte le esigenze che mi vengono in mente nel mio lavoro (es. piantare un chiodo) sarebbe un errore di valutazione mio, non un deficit dello strumento.

    Le capacità di chi porta a termine un lavoro si misurano anche dall’uso, dalla conoscenza dei sui strumenti fino alla scelta degli strumenti essi.

    Altrimenti è solo l’ennesimo tentativo di chi, non sapendo come lavorare, spera che ci sia qualcun altro che gli abbia risolto il problema.
    Magari con un click.


Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: