Interno · review prima dell'invio

Domande per Arianna — Facade.ai

Set di domande da mandare ad Arianna per valutare la fattibilità generale del progetto. Da rivedere con Giuseppe prima dell'invio.

Obiettivo: capire quanto è fattibile (e quanto difficile) costruire Facade.ai, prima di parlare di scope o prezzo. Ogni domanda è scritta in italiano, pronta da incollare nella mail; la riga "perché" è solo per noi.

Le domande mappano direttamente sulle incognite aperte della workflow map (Stage 0–8). 9 domande principali + 3 opzionali.

Materiale di riferimento

1
Ci confermi che abbiamo già il set completo del 80 West Broadway (disegni architettonici, leveling Excel del GC, markup di Simone)? E se esiste anche il markup originale "Highlighted Elevations" fatto dal GC — diverso da quello di Simone — ci farebbe piacere vederlo, per capire come il GC comunica il design intent.
Perché  Conferma che abbiamo l'input più grezzo; il markup del GC mostra come viene comunicato lo scope (≠ markup di takeoff di Simone).

Codificabilità del processo

2
Per capire quanto il processo è "codificabile": prendiamo la regola della terracotta del 80 West Broadway — "1 finestra = 6 elementi verticali + 1 orizzontale = 7 pezzi". Quanta parte del takeoff è fatta di regole nette come questa, e quanta invece dipende dall'esperienza e dal giudizio di Simone? E dove, di preciso, il giudizio umano è davvero insostituibile?
Perché  È LA domanda di fattibilità: regole deterministiche = automatizzabili; giudizio tacito = la parte difficile. Ancorata a un esempio reale per evitare un sì/no vago.
3
Ci daresti gli esempi più frequenti di informazioni mancanti e le "assumptions" che vi trovate a fare più spesso? L'idea è capire se sono ricorrenti — perché in quel caso diventano una checklist per componente che il sistema può anticipare.
Perché  Info mancanti ricorrenti → checklist automatizzabile (Stage 5). Se sono sempre nuove, è più difficile.

Variabilità (input e output)

4
Gli RFP arrivano sempre più o meno nello stesso formato (set di disegni architettonici + template di pricing del GC), oppure cambia radicalmente da GC a GC? In altre parole, quanto è "standard" l'input che ricevete?
Perché  Il singolo fattore che pesa di più sulla difficoltà: input standard → templatizzabile; caos → molto più duro.
5
Per un RFP tipico, su che tipo di file lavorate davvero: solo PDF, oppure a volte anche file CAD (DWG) o BIM (Revit/IFC)? Lo chiediamo perché nel set di 80 West Broadway c'erano anche dei DWG, e il formato del file cambia parecchio quanto è automatizzabile l'estrazione delle quantità.
Perché  CAD/BIM vs PDF è ciò che sposta di più la fattibilità dello Stage 2 (takeoff). Mostra anche che abbiamo davvero aperto i file.
6
I tipi di disegni da consegnare possono variare da progetto a progetto (a volte 2, a volte 5)? E lo stesso vale per il formato del breakdown finale richiesto dal cliente: cambia da GC a GC? Stiamo cercando di capire quanto l'output è "templatizzabile".
Perché  Variabilità dell'output = quanto è templatizzabile il deliverable finale.

Strumenti esistenti

7
Quali software di takeoff/estimating avete provato (Bluebeam, STACK, PlanSwift, Trimble…)? Dalla tua ultima mail ci sembra di aver capito che i limiti principali per le facciate siano essenzialmente due: (1) il takeoff software non individua automaticamente quali aree vanno selezionate per la quantificazione — quel lavoro di individuazione resta manuale; (2) non esiste un buon estimating software specifico per le facciate, che generi i prezzi e mantenga un database di informazioni. È corretto? Ci sono altri pain point che ci stiamo perdendo? In sostanza, il nostro ruolo sarebbe prendere in carico parte del lavoro che oggi fa il takeoff software — automatizzando anche l'individuazione delle aree — ed estenderlo fino al mondo dell'estimating. La vedi così anche tu?
Perché  Domanda build-vs-buy / white-space. La riformuliamo da scoperta a "conferma + espansione": dimostra che abbiamo ascoltato e capito il gap.
8
Perché non utilizzate gli RFI generati automaticamente dai takeoff/estimating software? È un problema di qualità/affidabilità, oppure è più una questione di abitudine e di fiducia nello strumento?
Perché  Rivela se l'automazione esistente è davvero inadeguata o solo non adottata (rischio di adoption).

Confini e valore

9
I prezzi finali da dove vengono: sempre dai preventivi dei fornitori per ogni singolo progetto, oppure avete dei listini interni o dei prezzi unitari storici? Ce lo chiediamo per capire se il sistema deve arrivare a produrre prezzi (e quindi serve un database prezzi) oppure "solo" organizzare le quantità e pacchettizzare la richiesta da mandare ai fornitori.
Perché  Definisce i confini dell'MVP: decide se tocchiamo lo Stage 6 (pricing) oppure no.
Opzionali tenere per la call, non per la prima mail

Le 9 sopra bastano a mostrare una comprensione strutturata del workflow senza far sentire Arianna "interrogata". Queste tre le terrei per la call, una volta che risponde.