# Introduzione [Nota per Costanza] Questa presentazione è rivolta ad un alto dirigente (sempre in area tecnica) dell'INPS per mostrare una possibile strategia di prezzo per la messa in convenzione del servizio DURC Online. Si tratta quindi di un breve riepilogo necessario per chi opera ad un alto livello di astrazione, volto a contestualizzare la discussione che avverrà sul modello proposto. # 1° slide ## Obiettivi Al momento la focalizzazione esclusivamente e puntualmente richiesta dalle divisioni preposte è sulla messa a punto di un modello di pricing per la gestione delle richieste massive di DURC da parte di enti convenzionati # 2° slide ## Descrizione Servizio La procedura attualmente disponibile gratuitamente prevede l’emissione del DURC previa fornitura di un singolo Codice Fiscale. Il servizio che si mira a porre in convenzione prevede l’automatizzazione su larga scala del suddetto processo consentendo l’instaurazione di molteplici istanze di richiesta e l’ottenimento dei dati in un formato facilmente gestibile da sistemi informativi. ### La Pipeline iniziale Il sistema automatizzato, già rilasciato consta di un “motore” atto a servire le richieste del Web Server predisposto per la procedura standard. Su richiesta dell’utente Web, il sistema ricerca all’interno di una data warehouse remota e delocalizzata (afferente allo stesso INPS, all’INAIL ed alle Casse Edili) i dati concernenti il DURC da generare. Qualora la procedura vada a buon fine, il documento di output viene generato in formato PDF ed inviato all’utente. In caso di fallimento la procedura richiede l’intervento del personale amministrativo il quale dovrà verificare i dati e mettersi in contatto con l’azienda in oggetto per la regola-rizzazione della situazione . ### Cosa fa il Webservice Il servizio in corso di valutazione consente all’utente l’invio di richieste multiple aggregate a lotti di 100 unità e quindi la ricezione dei rispettivi documenti DURC in formato XML, facilmente processabile all’interno di procedure automatizzate. Un Web Service su porta di dominio SPC, in questo caso, funge da interfaccia per l’utente esponendo i metodi necessari per richiamare l’Application Server con richieste multiple. Due procedure batch sono adibite in modo asincrono alla deserializzazione delle richieste ed al trasferimento dei risultati. Qualora l’evasione della pratica richieda più del tempo stabilito, viene inviata all’utente una notifica di fallimento della richiesta. Esistono politiche interne di premialità atte a disincentivare una simile occorrenza, essendo di norma attribuita, all’interno in, un’alta prorità all’emissione del DURC. ### Criticità Il Web Service produrrà una mole di richieste ben superiore a quella attualmente gestita dal sistema, questo, oltre al prevedibile aumento del carico sui server, statisticamente inficerà sul tasso di irregolarità e quindi sul coinvolgimento del personale amministrativo il quale dovrà evadere un numero assai più alto di pratiche nelle tempistiche fissate a norma di legge (30 giorni per l’intera procedura ed in particolare 14 giorni per la prima segnalazione all’azienda). # 3° Slide ## Ipotesi di lavoro Al fine di valorizzare correttamente l'impatto del costo del personale sul funzionamento di una procedura automatica ma con gestione manuale delle eccezioni, si è attinto alla statistica d'utilizzo del corrente servizio DURC Online. Dopo un accurato lavoro di data-mining, si è potuto verificare che l'alto tasso di eccezioni nelle procedure (26.9%) rende preponderante la componente umana su quelle infrastrutturali conducendo ad una semplificazione complessiva del modello. Altri parametri rilevanti sono stati misurati da dati forniti o stimati come segue: ### Evidenze: * **Numero medio di Richieste DURC giornaliere nel periodo (01/07/2015 - 31/03/2016)**: 11105 * **Percentuale di pratiche che necessitano di gestione manuale**: 26.9 % * **Percentuale di pratiche risolte senza errori**: 73.1 % * **Investimento iniziale di sviluppo**: K = 20000 € * **Costo di HelpDesk giornaliero**: 33.33 € (5000 € per il periodo Novembre-Giugno = 150 giorni lavorativi ) ### Stime * **Costo orario lordo di una risorsa umana amministrativa (impiegata nella gestione degli errori)**: 20 € * **Tempo medio necessario per la gestione di una pratica con errori**: 20' * **Costo di overhead di infrastruttura per pratica a buon fine**: 0.01 € * **Costo di infrastruttura giornaliero del sistema DURC** (inclusivo di costi di personale tecnico): 500 € ###Assunzioni vista la preponderante componente umana amministrativa, si potrà con un buon margine di sicurezza intraprendere le seguenti assunzioni circa parametri di ordine inferiore: **Crescita lineare dei costi di infrastruttura:** Si assume pessimisticamente che i costi di helpdesk, degli operatori tecnici e delle risorse energetiche (componenti del secondo corpo dell'equazione di cui sotto) possano crescere in modo continuo e lineare al crescere del traffico. L'upgrade di risorse hardware (le cui prestazioni -e conseguente deprezzamento a parità di potenza- sono nel tempo a crescita pressochè esponenziale, in ogni caso superlineare) può essere con un buon margine di sicurezza incluso nell'assunzione di cui sopra. In caso di investimenti particolarmente onerosi di rinnovo dell'hardware sarebbe invece opportuno rimodulare la variabile K (investimento iniziale). Con un proporzionale aumento del tempo di recupero dell'investimento sarebbe possibile ammortizzare un upgrade tecnologico senza intaccare il prezzo finale. **Assenza di rimborso a Casse Edili ed INAIL:** la possibilità di un rimborso a Casse Edili ed INAIL solamente paventata in sede di raccolta dei requisiti è stata modellata con la possibilità di un ricarico percentuale sul prezzo finale. In assenza di ulteriori indicazioni circa l'effettiva necessità e la quantificazione di tale parametro si è deciso per la soluzione proposta di escluderlo tramite l'assegnazione di una percentuale dello 0%. # 4° Slide ## Modello Sbranfi blablablabl ### Dati ### Formula (K *(1+m_ic ))/n(t_r ) +((i(t)+b(n(t)))*(1+m_ic )+h(t))/n(t) =x # 5° Slide ## Simulazioni Sbrimbi blablablabla ### Scenario 1 ### Scenario 2 ### Scenario 3 ### Mathematica