PaLoMa è nata da un cliente che ci ha chiesto un chatbot e ci ha portato a costruire un prodotto.

KitPusher è nato dalla strada opposta: non c’era nessun cliente a chiederlo. C’eravamo noi, dentro FITEC, a perdere giornate ogni mese a installare software tecnici sui PC del nostro parco. A un certo punto abbiamo deciso che valeva la pena costruire la soluzione che ci serviva utilizzando le nostre competenze di sviluppo software.

Questa è la storia.

Il problema: due ore a utente, moltiplicato per troppi utenti

Il parco PC di FITEC è quello di una società che fa consulenza tecnica seria. Non si parla di Office e qualche browser — si parla di software CAD complessi (NX, Catia), suite PLM come Teamcenter, tool di simulazione, pacchetti di sviluppo specifici per cliente. Software pesanti, configurati con precisione, che richiedono passaggi specifici per essere installati correttamente.

Il flusso che usavamo prima di KitPusher era questo: per ogni installazione contattavamo l’utente, schedulavamo una sessione di remote desktop, interrompevamo il suo lavoro, eseguivamo l’installazione, verificavamo, lo restituivamo al suo posto. Tempo medio per singolo utente: circa due ore — comprensive di coordinamento, attesa, installazione vera e verifica.

Due ore a utente, su un parco di consulenti tecnici, moltiplicate per le installazioni periodiche, significava costi nascosti pesanti. Costi misurabili in ore-uomo nostre e in produttività bruciata degli utenti, costretti a fermarsi.

Era un’attività meccanica. Il tipo di attività meccanica che, se la stai facendo manualmente nel 2024, qualcosa non torna.

Cosa NON era un’opzione

La via ovvia sarebbe stata adottare uno dei tool MDM enterprise che esistono — Microsoft Intune, SCCM, soluzioni terze. Tre problemi.

Il primo è banale: per FITEC stessa, internamente, non avevamo né il budget né le approvazioni per adottare quelle soluzioni. Non perché non fossero brave a fare il loro mestiere — perché erano sproporzionate per il nostro caso specifico.

Il secondo è architetturale: praticamente tutte le soluzioni enterprise di software distribution richiedono di installare un agent sui client. Un piccolo servizio sempre in esecuzione che riceve comandi dal server centrale. Significa aprire un’analisi di compliance, valutare l’attack surface, mantenere uno stack client-side, gestire le versioni dell’agent stesso. Per chi conosce ICT enterprise: significa lavoro che non avevamo.

Il terzo era riconoscere quello che avevamo in casa. FITEC ha competenze di sviluppo software profonde e competenze ICT solide. Costruire era praticabile — anzi, era il nostro mestiere.

Da qui la decisione: agentless dal giorno uno. Niente da installare sui client. Tutto orchestrato da un nodo centrale che parla ai PC con protocolli che Windows già conosce — SMB3, RPC, PsExec — senza chiedere nulla di esotico.

La prima versione: script

Come spesso succede, la prima versione di KitPusher non era un prodotto. Era una collezione di script. PowerShell, batch, robe artigianali, accumulate nel tempo da persone diverse in FITEC, ognuna ottimizzata per il caso specifico che aveva davanti.

Funzionavano. Ma vivevano in uno stato di costante attrito:

  • Difficili da mantenere. Ogni script aveva un autore originale, un sapere implicito su come andasse usato, edge case scritti in commenti — quando andava bene.
  • Difficili da deployare. Ogni rollout era una piccola epopea di copia, configurazione, test, “hai aggiornato la versione giusta?”.
  • Tecnologie che rallentavano il sistema. Alcuni passaggi erano risolti con strumenti che funzionavano ma costavano performance sui client durante l’esecuzione. Troppi impatti.
  • Audit approssimativo. Quando ti chiedevano “cosa è stato installato il mese scorso sul PC di Tizio?”, la risposta era approssimativa e basata su log sparsi.

Questa fase ci ha insegnato moltissimo — non sui successi, ma sugli errori. Quasi ogni cosa che oggi KitPusher risolve come prodotto è un problema che abbiamo vissuto prima nella versione script.

La svolta operativa: l’upgrade di Teamcenter + CAD

Il momento che ha trasformato KitPusher da “stiamo lavorando su un tool” a “questa cosa serve davvero” è stato un upgrade di Teamcenter con i CAD annessi.

Doveva essere fatto su tutti i client. Comprendeva installazioni di nuove versioni, esecuzione di script di configurazione, applicazione di patch specifiche per ambiente. Con il metodo tradizionale — coordinamento utente per utente, sessione remota per sessione remota — sarebbe richiesto settimane. Non tanto per l’esecuzione tecnica, quanto per la logistica: schedulare, coordinare, ricontattare, ripianificare.

Con KitPusher la stessa cosa è stata gestita in modo radicalmente diverso. Coda di task in parallelo, esecuzione orchestrata, tracciamento di ogni passaggio, gestione strutturata degli errori. Le settimane sono diventate ore. E ogni operazione era loggata, verificabile, riconducibile.

Quel rollout è stato il momento in cui abbiamo smesso di trattare KitPusher come “un nostro tool interno” e abbiamo iniziato a pensarlo come prodotto da offrire a terzi.

L’audit: il valore che non sapevamo di aver costruito

C’è una cosa che KitPusher fa che all’inizio non avevamo immaginato come killer feature, e che si è rivelata essere il punto di forza che cerchiamo di mostrare agli altri.

KitPusher registra tutto: chi ha installato cosa, su quale macchina a chi, quando, con che esito. Successi, errori, codici di ritorno, output dei processi. È un log strutturato, query-able, completo.

A cosa ci serve? A due cose, scoperte progressivamente.

Verificare il nostro operato verso il management interno. Quando qualcuno chiede “perché abbiamo speso X ore questo mese su un rollout?”, la risposta non è un’opinione: è una tabella. Cosa è stato installato, dove, quando, da chi. Niente fumo.

Verificare verso il cliente quando il rollout è per loro. Una parte del nostro lavoro è installare e mantenere ambienti tecnici sui PC dei clienti che serviamo. Quando finisce il rollout, possiamo consegnare al cliente non solo “fatto” — possiamo consegnare la prova esaustiva di cosa è stato fatto, su quali macchine, con che esito. Questo cambia completamente la natura della consegna: il report parla chiaro.

Per chi gestisce ICT in un’azienda seria, questo è il punto in cui un audit trail esaustivo smette di essere bureaucratic overhead e diventa il prodotto.

Da script a prodotto: la riscrittura

Quello che oggi è KitPusher non è una versione raffinata dei vecchi script. È una riscrittura completa, frutto di anni di errori e problemi vissuti prima sulla nostra pelle.

Le scelte tecniche sono state guidate da quello che ci aveva fatto soffrire:

Niente agent sui client, per le ragioni di compliance, attack surface e manutenzione dette sopra.

Crittografia seria per le credenziali in transito e a riposo — AES-256-GCM, derivazione chiavi con PBKDF2 a 600.000 iterazioni — perché un tool che gestisce credenziali per installare software in modalità privilegiata su decine di macchine non può permettersi una crittografia approssimativa.

Audit log strutturato dal giorno uno, non come feature aggiunta tardi sopra qualcos’altro.

Push parallelo nativo, perché esecuzione sequenziale su un parco di consulenza significa perdere il vantaggio principale prima ancora di partire.

On-premise come default, perché i clienti che abbiamo in mente — aziende industriali, manifatturiere, tecniche — hanno spesso reti interne in cui la connettività cloud è limitata, gestita, o assente per scelta.

Cosa abbiamo imparato

La lezione che porteremo con noi in qualunque prodotto futuro è una sola: costruire dall’esigenza propria, vissuta, ripetuta, è il modo più sicuro di costruire qualcosa di utile.

KitPusher non è il risultato di un brainstorming di prodotto in una sala riunioni. È il risultato di centinaia di sessioni di remote desktop che ci hanno fatto venire mal di testa. Prima quando lo facevamo manualmente. Poi quando lo facevamo con script. Poi quando ci siamo accorti che il problema non era automatizzare ulteriormente — era cambiare paradigma.

Per chi gestisce ICT in azienda e si trova nella nostra stessa situazione (parco PC tecnico, software pesanti, audit richiesti, no budget per MDM enterprise), il consiglio è semplice: parti dal flusso che ti costa più tempo. Cronometralo. Capisci se il problema è di tooling o di processo. Se è di tooling — e spesso lo è — la costruzione di uno strumento dedicato si ripaga in fretta. Specialmente se devi giustificare il tuo operato a qualcuno che vuole vedere prove, non racconti.

KitPusher esiste perché stavamo perdendo troppo tempo. E perché eravamo nella posizione fortunata di poterci costruire la soluzione che ci serviva. Adesso la offriamo anche ad altri.