![\"comporre_b1\"](\"http:\/\/www.expertconfigurator.com\/wordpress\/wp-content\/uploads\/2015\/08\/comporre_b1.jpg\")
<\/a><\/p>\nSi dice poi che per ogni tipologia di azienda deve essere adottato uno specifico configuratore.<\/p>\n
Se sei un’ azienda assemble-to-order (ATO) hai bisogno di un tipo di configuratore.<\/p>\n
Se sei un’ azienda Engineered-to-Order (ETO) hai bisogno di un altro tipo di configuratore e cos\u00ec via…<\/p>\n
Non \u00e8 cos\u00ec. Il motore del sistema di configurazione pu\u00f2 essere unico, a patto di risolvere il problema della classificazione dei prodotti\/servizi<\/a><\/span> seguendo i naturali \u201cusi e costumi umani\u201d.<\/p>\n e.g. In merito a ci\u00f2, qualche riga pi\u00f9 sotto ho preparato un piccolo esempio che spero possa aiutare.<\/p>\n La modalit\u00e0 tramite la quale vengono realizzate le interfacce utente di un configuratore merita un inciso di riflessione.<\/p>\n Pi\u00f9 l’interfaccia utente riesce ad essere \u201cadattiva\u201d (in grado di adeguarsi alla capacit\u00e0 cognitiva dell\u2019utente), pi\u00f9 questa riuscir\u00e0 ad aiutare efficacemente il cliente nella configurazione del prodotto\/servizio desiderato.<\/p>\n Sul piano tecnico sono oggi numerose le piattaforme di sviluppo che consentono di generare a \u201crun-time\u201d le forms d\u2019interfaccia pi\u00f9 idonee per ogni situazione.<\/p>\n Tornando al tema centrale di questo post; come combattere la \u201ccomplessit\u00e0\u201d di un sistema di configurazione, migliorando la propria capacit\u00e0 di costruire astrazioni di prodotti\/servizi… un buon punto di inizio potrebbe essere quello di passare per un negozio di giocattoli e comprare una confezione di Lego.<\/p>\n Perch\u00e9 i mattoncini hanno avuto successo?<\/p>\n I mattoncini hanno ancor oggi successo perch\u00e9 sono semplici. I Lego dispongono di un sistema di normalizzazione che permette ad ogni mattoncino di interagire con un altro ed \u00e8 facile capire se esiste una compatibilit\u00e0 o incompatibilit\u00e0 d\u2019incastro.<\/p>\n Con le cose semplici si possono costruire cose complesse. Da leggere come: se uno capisce “dove stanno i mattoncini” facile che poi riesca a realizzare quanto desidera.<\/p>\n <\/a>Se invece non si riesce a scomporre la complessit\u00e0 identificando i mattoni elementari… la strada \u00e8 in salita.<\/p>\n Per comprendere il vantaggio offerto dal sistema di codifica degli items SKU basato sulla teoria degli oggetti<\/span><\/a>, ecco un esempio che pone a confronto due metodi che possono essere utilizzati per generalizzare una semplice distinta base di un prodotto.<\/p>\n Situazione:<\/strong> si deve realizzare un prodotto composto da due assi di legno di stessa essenza e diverso spessore da unire con un chiodo.<\/p>\n Problema:<\/strong> definire una struttura dati idonea a generalizzare tutte le possibili varianti del prodotto considerato, cos\u00ec da ottenere una lista pezzi finale (distinta base) costituita da tre legami:<\/p>\n Soluzione:<\/strong> la generalizzazione sar\u00e0 svolta con i seguenti metodi:<\/p>\n –metodo A<\/em><\/span> (classico)<\/strong>, ovvero la normale tecnica utilizzata dai configuratori “a regole”<\/strong> presenti nei sistemi “ERP majors” che codificano gli items SKU con il metodo del \u201ccodice item parlante\u201d. e.g. il codice item viene costruito concatenando pi\u00f9 sottostringhe,\u00a0 ognuna della quali identifica una caratteristica dell item da classificare.<\/p>\n
\n<\/a><\/p>\n
\n
\n\n
\n