Newsgroup: it.comp.appl.access
Titolo: FMEA/FMECA

Qualcuno ha avuto modo di lavorare sull'argomento in Oggetto dal punto di vista sviluppo sw...?
 
Lavoro con questo metodo di analisi in campo industriale, spesso con sw abbastanza complessi... che ovviamente generano solo i risultati in varie forme a seconda del fine.
 
Mi chiedevo, pur consapevole sia un ambito estremamente specialistico e probabilmete compmesso di nicchia, se qualcuno avesse mai affrontato l'argomento.
 
@Alex 

 Mi chiedevo, pur consapevole sia un ambito estremamente specialistico e probabilmete compmesso di nicchia, se qualcuno avesse mai affrontato l'argomento.
 
 
Da alcuni anni supporto un mio cliente nell'industria automobilistica 
chi ha sviluppato un programma con Access per la gestione della qualità 
che include anche FMEA.
 
Proprio dalla settimana prossima lo supporterò 
nell'internazionalizzazione del programma. Certo lui è l'esperto per la 
gestione qualità, FMEA, ISO ecc. Io faccio solo il consulente per parti 
complessi nella struttura e programmazione con Access e SQL Server.
 
-- 
Ciao
Karl
*********
http://www.AccessDevCon.com
 
Access FAQ: 
http://www.donkarl.com/it
 


Ciao Karl, mi occupo anche io di questi problemi, la cosa è estremamente interessante proprio in ambito opertivo industriale.
Noi abbiamo SAP R/3 che fa una quota parte di questo lavoro, ma non tutti i processi possono essere gestiti con SAP R/3, sarebbero troppo complessi da strutturare.
 
Pensavo quindi di sviluppare un prodotto con Access per la gestione, più comoda ed immediata dedicata ad analisi FMEA di Process, Project and Safety.
 
Sul tema ho una "sufficiente" conoscenza, il mio vantaggio è sapere cosa voglio ottenere.
Ora ci sono alcune cose su cui servirebbe parlare in modo specifico, ma ti vorrei fare qualche domanda che spazia su diversi temi, se hai modo di darmi supporto, ovviamente espongo prima i temi, poi la mia attuale idea, su cui ho qualche riserva...
 
1° Hai realizzato una gestione Gerarchica a Livelli NON FINITI dei RIschi...?
   In questo caso come organizzi la visualizzazione in HMI...?
 
2° Algoritmo di Calcolo della Soglia di intervento
 
3° Elaborati Grafici
 
 
Espongo il mio attuale approccio di implementazione del SW:
1° Il primo punto è un filo controverso, ad oggi ho realizzato 3 Livelli Fissi:
   1-Progetto
   2-Fase
   3-SottoFase(Rischio vero e proprio con le assegnazioni dei valori di SOD)
 
   Il motivo per cui ho limitato a questi 3 Livelli è principalmente per una questione Grafica... le Sottomaschere non sono il massimo per la gestione Gerarchica... ed un TreeView è limitato in questi casi.
   Sicchè gestisco i primi 2 Livelli a TreeView mentre il 3°, quello su cui inseirre la valutazione, in SubForm.
 
   Sto provando ad effettuare un passaggio alla MsFlexGrid, perchè mi consentirebbe di implementare una vera e propria Gestione Gerarchica, implementando in prima Colonna il sistema di EXPAND/COLLAPS dell'Item e sfruttando i MERGE delle CELLE...
 
   Questa idea di usare l'Activex di MS è estremamente funzionale e flessibile... oltre a facilitare l'Export in EXCEL... ma... è un Activex e non so come andrà nel futuro...
 
2° L'algoritmo di calcolo della soglia di ALLERT dipende dal metodo di analisi chiaramente, ci sono molte scuold di pensiero, nonchè l'apporoccio FMEA 4th o il SixSigma che entra ancora più nel dettaglio del lavoro anche in aspetti economico operativi...
Nel mio caso mi fermo a lla valutazione FMEA, applicando le ultime indicazioni emerse... ovvero consento al gruppo di analisi di definire 3 tipologie di metodo:
 
  a) Soglia FIssa che agisce su RPN(S*O*D)
  b) Soglia % sul Massimo RPN impostabile... ad esempio 80%
  c) Critical Matrix basata su S*O in una matrice 10*10 in cui definisco le Aree Sicure, quelle con Intevento richiesto(S>8) e nelle aree di dubbio associo un valore di D minimo.
 
  L'approccio che preferisco è il [c]
 
3° Report
  Su questo mi trovo molto in difficoltà... a parte un PDF con le tabelle di Valutazione e di analisi, volevo realizzare grafici e rappresentazioni tipo FishBone su cui fatico molto a pensare ad una soluzione, anche se nel report la posssibilità grafica è ampia... , ma il problema è se si implementa una gestione Gerarchica.
 
So che sono domande abbastanza complesse... ma se hai possibilità, come sviluppatore di darmi qualche elemento di confronto, almeno capisco anche altri punti di analisi...
 
Se poi hai qualche cosa da mostrarmi... ;-) meglio...
 
Ciao Karl
 
@Alex

 ... se hai possibilità, come sviluppatore di darmi qualche elemento di confronto...
 
Mi dispiace, ma lo sviluppatore nell'impresa ha creato quasi tutta la 
parte FMEA dell'applicazione. L'ho solo aiutato un po' con problemi di 
dettaglio, sbagli, vis. delle matrici ecc. ma non sono stato coinvolto 
molto.
 
Inoltre è ca. 1 anno che non ero in quell'impresa. Solo adesso hanno 
deciso di internazionalizzare la cosa. Puo darsi che nel corso dei 
prossimi mesi mi occuperò anche più della parte FMEA, ma fino a questo 
il mio parere non vale la pena.


Capisco, infatti come ho premesso è un tema specialistico di settore... e spesso chi ci lavora non programma e viceversa...
 
Grazie ugualmente Karl.
 
@Alex


 
 
Non mi è chiara l'affermazione "ed un TreeView è limitato in questi casi".
 
Tu hai sviluppato un treeview in puro Access piuttosto flessibile, se ben ricordo.
 
Saluti

 Saluti
 
Ciao Simone, l'argomento è più complesso di quanto potrebbe non sembrare... non so se hai mai affrontato analisi di tipo FMEA sulla valutazione Rischi...
Il sistema è ragionevolmente gerarchico, senza Limiti... sicchè la rappresentazione tipo sarebbe quella di Rappresentare la gerarchia con il TreeView e la parte di Dettaglio con una normale Maschera Continua o DataSheet...
Questo certamente consentirebbe la gestione, ma, nell'ottica di un'analisi FMEA si perde la correlazione gerarchica della conseguenza del rischio figlio sul padre...
 
Per assurdo la miglior visualizzazione la offre EXCEL cosa che con Access è realizzabile con una GridView di tipo Gerarchico, che funziona molto bene peraltro ma la gestione è assai complicata perchè si passa da Gerarchico a Sequenziale.
 
Ogni Rischio può essere Figlio di Altri Rischi ed ogni rischio richiede una propria analisi specifica.
 
Altra Possibilità, ma troppo parziale, era di usare le DataSheetView con SubDatasheetView... ma ha sempre vincoli di rappresentazione su Gerarchie AutoReferenziali.
 
Questo poi pone problemi anche nella Reportistica... non so se ti sia mai capitato di generare un REPORT a gerarchia non definita, quindi di cui non sai a priori quanti livelli di profondità sono da gestire... io non ci sono riuscito per capirci in modo semplice con Access, ed ho optato quindi per SERIALIZZARE la gerarchia e trasferirla in Excel sfruttando i Raggruppamenti...
 
Non so se ho reso l'idea, effettivamente faccio un po fatica a trasmettere il problema che è sia Tecnico che Grafico operativo, ma se ti è capitato di operare in questo settore sicuramente ne comprendi bene la dinammica.
 
@Alex

 
 
 
 
Facciamo un esempio terra-terra: un articolo strutturato destinato a una produzione.
Ipotizzo che il prodotto finito da creare sia composto da più d'un livello di componenti (magari N) che vengono realizzate internamente con più cicli di produzione.
 
Articolo lampadario, composto da:
 
X Lampadine
y Cavi
1 CorpoCentrale
 
L'articolo CorpoCentrale a sua volta è costituito da:
 
Z MateriaPrima
W Viti
 
 
stampando su report l'articolo lampadario, vorrei una rappresentazione tipo:
 
Lampardario
   --- X Lampadine
   --- Y Cavi
   --- 1 CorpoCentrale
         --- Z MateriaPrima
         --- W Viti
 
 
Questa dovrebbe essere una gerarchia simile alla tua casistica, è così?
 
 
 
 


Una gerarchia tipo 
DI.BA
 è abbastanza banale da ottenere in un Report se si usa una campo Testo con Font a spaziatura costante... Currier esempio, e si realizzano stampe di 
DI.BA
 a N livelli...
 
In altro modo se non hai un Livello massimo Predefinito che ti consente di creare una Query con tabelle in SelfReference... inizia a non essere così semplice...
 
Nel mio caso l'argomento di cui parliamo ha esigenze un poco più personalizate e personalizzabili, come la possibilità di AGGIUNGERE COLONNE(Campi), o formattare con F.C. con variabilità di dimensione del testo che impegnano anche tutto la capacità dei 255 CHAR.
Ci sono da un minimo di 30 Campi/colonne ad un massimo di 50
 
Questo esclude la possibilità di usare una TextBox, e nemmeno una TextBox in RTF perchè mancano le divisioni... e perchè il testo deve allargarsi in Verticale.
 
Ho ottenuto una cosa funzionale sia con Access gestendo le Maschere in modalità DataSheet e SubDataSheet, ed un TreeView, ma no è il massimo...
 
Prova a vedere questa Immagine, qualche cosa aiuta:
https://aldservice.com/images/stories/fmeca1.gif
 
 
@Alex

 
https://aldser
 
 
 
Certo l'immagine è piccola, ma sembra tutto risolto. 
Quindi non è chiaro cosa non ti soddisfi o tu non riesca ad ottenere veramente (il Report?).
 
Saluti
 
 
 

Magari prova ad espormi come realizzi un Report di una DIBAovviamente gerarchica magari sono io che non ci arrivo e mi perdo.
Diciamo una struttura gerarchica come hai esposto tu prima sopra anche se solo a 3 livelli.. ma se dici non rappresentare un limite ti ascolto con estremo interesse perché mi sfugge.
 
Per il resto quello che manca in access e il controllo gerarchico che vedi in altro che non è un Treeview.
 
Ciao
@Alex


 
 
Posto che esiste un limite fisico alle indentazioni gerarchiche, compatibilmente con le dimensioni del foglio.
 
Articolo lampadario, composto da:
 
X Lampadine
1 FustoMetallo
 
L'articolo FustoMetallo a sua volta è costituito da:
 
1 CorpoMetallo
Y Bulloni
 
 
   Lampadario
   ----- X Lampadine
   ----- 1 FustoMetallo
         -----  1  CorpoMetallo
         -----  Y  Bulloni
 
 
Partiamo dalla tabella contenente le "strutture":
 
IDArticolo            (non chiave primaria, contiene l'ID articolo Padre)
IDArticoloCollegato   (articolo figlio)
QtaComposizione
 
 
Supponi che gli ID siano numerici (ma fa lo stesso) come segue:
 
Articolo         IDArticolo
 
Lampadario       41
Lampadine        42
FustoMetallo     43
CorpoMetallo     44
Bulloni          45
 
 
dopo aver inserito le strutture con apposita Form, la tabella "strutture" contiene:
 
IDArticolo      IDArticoloCollegato       QTA
41              42                        X
41              43                        1
43              44                        1
43              45                        Y
 
 
Il Report "gerarchico" è basato su una tabella temporanea locale che viene popolata come segue:
 
IDKey (identity)   IDGruppo    IDArticolo   Codice      Livello    Qta   etc.
1                  41          41           Lampadario  1
2                  41          42           Lampadine   2
3                  41          43           Fusto       2
4                  41          44           Corpo       3
5                  41          45           Bulloni     3
6                  43          43           Fusto       1
7                  43          44           Corpo       2
8                  43          45           Bulloni     2
 
 
 
I campi IDKey e IDGruppo permettono di mantenere ordinati e coerenti i dati in stampa.
 
Su evento Corpo_Format puoi indentare gli oggetti nel corpo, sfruttando il contenuto del campo "Livello":
 
 
Me!TextBoxN.Left = ValorePartenza + ([Livello] * Costante)
 
 
Mah, chissà se è capibile.
 
Saluti da Simone
 
 
 

 
Forse si legge meglio:
 
 
Key     IDGruppo       IDArt    CodiceArticolo     Livello     etc.
1	41       	41	Lampadario	   1
2	41              42	Lampadine	   2
3	41        	43	Fusto	           2
4	41      	44	CorpoMetallo	   3
5	41      	45	Bulloni  	   3
6	43              43	Fusto	           1
7	43	        44	CorpoMetallo	   2



Simone, alla fine rendi SEQUENZIALE una Gerarchia in una TempTable, come già faccio io per esportare in Excel, ed in effetti NON c'è una soluzione diversa... che io sappia, sul riposizionamento del LEFT direi soluzione scolastica e chiara.
P.S., ci conosciamo da qualche mese... mi auguro non pensassi che fin quì non ero arrivato... ;-)
 
Il problema è come hai già giustamente compreso è dato sia dal Livello di Profondità aggravato dal NUMERO di COLONNE e dal loro contenuto da visualizzare, che come ti ho precedentemente accennato prima il numero di COLONNE/CAMPI da visualizzare è VARIABILE, ovvero l'utente si configura l'editor per accogliere i requisiti necessari.
Significa che nella Tabella ho predisposto 50Campi di cui 30 sono Standard Minimali, gli altri 20 Visualizzabili a necessità.
 
Come sai Access stampa al massimo in A3, e rendere visibile 50 COLONNE(Campi) di cui molti Descrittivi, tutti in FILA(quindi allineati in alto) in un Formato A3 credo tu convenga con me, potrebbe essere di difficile lettura... anche se si imposta l'AutoSize in Verticale...
 
Spero di aver chiarito meglio.
 
Grazie
 
@Alex

 Spero di aver chiarito meglio.
 
 
Beh, 50 campi solo nel caso peggiore (utente che sceglie tutti gli opzionali), altrimenti farai stampare solo quelli necessari: utilizzerai Array di controlli indexati, per rendere visibili solo gli oggetti scelti dall'utente...
 
Magari la lettura non sarà straordinaria, ma che alternative vedi?
 
Ciao!
 
 

 Ciao!
 
I campi come MINIMO sono 30, e ti assicuro che sono ILLEGGIBILI, e questa documentazione è Certificativa... quindi deve essere leggibile.
 
Come dicevamo i problemi sono 2 di sostanza:
1) Gestione delle Maschere di Interfaccia ci sono 2 Soluzioni
   a) Con qualche compromesso da accettare, uso un TreeView per la Gerarchia ed una Form/SubForm entrambe in modalità DataSheetView(consentono il Resize)
   b) TreeView e HierachicalFlexGrid, questa soluzione è ottima, una PIZZA per il codice discretamente complesso, ma usando CLASSI invece di TempTable è velocissima.
 
2) Gestione Reportistica, in questo caso non ho 2 soluzioni in quanto il REPORT è illeggibile, già fatto diverse prove... ed ho esportato in EXCEL, il lavoro viene bene, funzionale... è da considerare un compromesso, si può stampare fino in A0 su PDF.
 
Questo è quanto.
@Alex


 
 
Quindi hai già risolto tutto, come pensavo.
 
Comunque eviterei la soluzione b): sarà veloce ma ti affidi a una componente che non ha futuro. Se poi il codice è complesso ti rompi i coglioni a riprenderlo in mano tra qualche mese o anno.
 
Non m'è chiaro in che modo sia più leggibile il pacco dopo averlo esportato in excel, ma mi fido ;-)
 
Saluti
 
 
 

 Saluti
 
Ciao Simone, grazie per lo scambio.
 
@Alex


 
 
Ok, però prenderei in considerazione un'altra strada, valutando una delle funzionalità più sottovalutate di Access: lo "stampa finestra", che non è affatto un PRINT del video, ma un vero e proprio report generato al volo partendo dalla Form.
 
Qui magari non basta, ma può essere una soluzione interessante in varie altre situazioni.
 
Abbiamo detto che hai scelto la soluzione a) quindi ti appoggerai a un Temporaneo concettualmente simile a quello del mio esempio.
Supponiamo che tu dia in pasto tale struttura dati a una Form/SubForm DataSheet. Chiaramente per indentare i dati ci si deve arrangiare (usando sequenze di Blanks) ma hai il vantaggio di poter ridimensionare le colonne come ti pare, manualmente in altezza e/o larghezza, e automaticamente al contenuto.
 
 
Su pressione di un button:
 
   DoCmd.RunCommand acCmdPrint
 
e scende su carta. Se supera le dimensioni del foglio crea un'altra pagina.
 
 
 
 
 
 
 
 

 e scende su carta. Se supera le dimensioni del foglio crea un'altra pagina.
 
Non posso usare 2 fogli... deve essere su una sola pagina in ORIZZONTALE eventualmente le N pagine solo in verticale...
 
Devo provarlo in ogni caso, voglio capire se il Print è un AsView, quindi taglia le colonne non visualizzate accessibili da SCROLLBAR_HORIZONTAL oppure se è intelligente e stampa tutto... 
 
Ci guardo.
 
@Alex


 
 
Se parliamo di una SubForm, si possono stampare tutte le colonne fino al limite del foglio, ma non basta il comando acCmdPrint
 
Saluti