Come funziona {yourcompany}os: strato processi, strato implementazioni, schema aperto

Parte un nuovo progetto. Qualcuno digita il nome nell'ERP. Qualcun altro crea la cartella in SharePoint. Una terza persona configura la casella di posta, e i piani finiscono nel CDE. Cinque sistemi, ognuno perfettamente funzionante per conto proprio, nessuno consapevole che stanno tutti descrivendo lo stesso progetto. Nessuno ha scelto questo. È ciò che succede quando ogni strumento tiene la propria copia della verità e le persone sono lo strato di integrazione tra loro.

{yourcompany}os è lo strato che si posa sopra quello stack e lo tiene insieme. Non sostituisce il vostro ERP, la vostra archiviazione, la vostra posta o i vostri strumenti specialistici. Fa girare il processo attraverso di essi, così il progetto esiste una volta sola come processo e ogni sistema riceve ciò che deve sapere.

Sotto, questa separazione è deliberata: il processo, i sistemi con cui parla e il modello di dati sono tre strati indipendenti invece di un unico blocco. Questo articolo mostra cosa fa ciascuno strato, cosa vi risparmia e come si comportano i tre quando uno strumento del vostro stack cambia.

Cosa resta e cosa cambia davvero

Resta esattamente com'è	Cosa cambia
Il vostro ERP, CRM, archiviazione, posta e CDE	Un processo li attraversa, invece di una persona che porta il lavoro da uno all'altro
Gli strumenti che le persone già conoscono	Le attività arrivano nella posta e nell'archivio esistenti, non in un'altra interfaccia da imparare
Dove vivono i vostri file	Quale versione è corrente lo stabilisce il processo, non una convenzione di denominazione
IFC come formato di scambio	Sopra si posa uno schema orientato al workflow, così le applicazioni possono interrogare e validare

Il vantaggio pratico di essere uno strato invece di una piattaforma: non c'è nessun progetto di migrazione. Nulla deve essere spostato fuori dai sistemi in cui vive prima che il primo processo possa girare, ed è per questo che un primo processo chiave va in produzione in 1-2 giorni invece che dopo un rollout. Nessuno deve essere riformato su una nuova interfaccia, perché il lavoro viene consegnato negli strumenti che le persone già aprono ogni mattina. E quando l'unica persona che conosceva tutti i passaggi va in vacanza o se ne va, i passaggi sono nel processo e non nella sua testa.

I tre strati

Strato	Che cos'è	Cosa vi porta
Processo	Definizioni BPMN che il vostro team scrive e possiede	Il flusso sopravvive ai cambi di strumenti e di personale e resta verificabile
Implementazione	Un connettore per gruppo di capability (archiviazione, ERP, posta, IA, pagamenti, ...)	Cambiare fornitore è una modifica di configurazione, non un progetto di rifacimento
Modello di dati	Lo schema aperto contro cui entità e processi leggono e scrivono	Potete ispezionare ed esportare i vostri dati senza chiedere il permesso

La maggior parte degli strumenti di workflow fonde tutto questo in una cosa sola: il "flow" è l'integrazione è la struttura dati, tutto definito nello stesso canvas no-code e tutto perso insieme se cambiate fornitore. {yourcompany}os tiene i tre pezzi sostituibili in modo indipendente, ed è esattamente questo che rende sicuro posarlo su uno stack in cui avete già investito.

Strato 1: il processo, la parte che sopravvive ai vostri strumenti

Un processo in {yourcompany}os è una definizione BPMN, non un'esecuzione di flow. La distinzione sembra accademica finché non cambia uno strumento. Un'"esecuzione di flow" (Power Automate, Zapier, la maggior parte degli strumenti iPaaS) è un singolo passaggio che parte, fa il suo lavoro e termina. Non ha memoria di sé come entità, quindi appena un progetto si estende su settimane e più passaggi di consegna non resta nulla di durevole da indicare. Una definizione di processo BPMN è un artefatto: ha fasi, sottoprocessi, gateway e un ciclo di vita che sopravvive a ogni singola esecuzione.

Cosa significa nella pratica quotidiana:

• Una sola identità di progetto invece di cinque. Denominazione, registrazione nell'ERP (per esempio in SAP o bexio), configurazione, esecuzione e chiusura sono fasi di un solo processo, ognuna che tocca sistemi diversi ma tutte che puntano allo stesso progetto. È il problema del copia-incolla dell'apertura, risolto in modo strutturale. Il dettaglio completo è in Creare un progetto: un ancoraggio stabile attraverso i vostri strumenti.
• Il lavoro lungo non si sfalda nei passaggi di consegna. Configurazione e consegna girano come sottoprocessi propri attraverso gli strumenti, ma restano fasi del processo padre e non script autonomi che terminano e dimenticano.
• L'IA aiuta senza comandare. Un agente può fare ricerca, classificare o redigere all'interno di un passaggio; gateway e persone decidono cosa succede dopo, e ogni passaggio viene registrato. Utile quando dovete spiegare a un cliente o a un revisore perché qualcosa è stato approvato.
• Potete leggere il vostro processo. Poiché è BPMN e non JSON di flow proprietario sepolto in un canvas SaaS, la definizione è leggibile e portabile, e una persona appena assunta può guardare il diagramma invece di chiedere in giro.

Sostituite un ERP, un fornitore di archiviazione o un viewer, e la definizione del processo non cambia. Cambia solo l'implementazione risolta sotto, che è lo strato successivo.

Strato 2: le implementazioni, dove il collegamento avviene davvero

Un passaggio di processo non nomina mai un fornitore. Nomina un gruppo di capability, ed esattamente una implementazione è configurata per servire quel gruppo. I gruppi di capability sono cose come archiviazione, posta, ERP e contabilità, CDE, visualizzazione piani, BIM, IA o pagamenti. Durante l'onboarding puntate ogni gruppo necessario a ciò che già gestite, e la logica di processo resta identica indipendentemente dalla scelta.

Implementazioni oggi disponibili per gruppo:

• Archiviazione: Nextcloud, Google Drive, Microsoft 365 (SharePoint o OneDrive via Microsoft Graph)
• Posta: Outlook / Microsoft 365, Gmail, Nuntly (per caselle di progetto e invio di sistema)
• ERP / contabilità: bexio (indirizzi, ERP, contabilità)
• CDE: Trimble Connect
• Visualizzazione piani / BIM: motore interno o iolabs (viewer piani), abstractBIM (BIM e IFC)
• IA: Infomaniak AI (hosting svizzero, predefinito), OpenAI, Anthropic, Google Gemini o il vostro modello come BYO LLM
• Pagamenti: Stripe

La meccanica completa è in Implementazioni: collegare i sistemi del cliente.

Da questo derivano due cose, del tipo che si apprezza solo dopo due anni:

1. Cambiare sistema è una modifica di configurazione, non un progetto di rifacimento. La vostra azienda passa da Nextcloud a SharePoint, o cambia fornitore di IA per una variazione di prezzo. Il processo che consuma "archiviazione" o "IA" come capability continua a girare intatto. Confrontatelo con un flow no-code in cui il fornitore è cablato in ogni nodo.
2. Un sistema mancante si aggiunge, non blocca. Se qualcosa nel vostro stack non ha ancora un'implementazione, se ne aggiunge una per quel gruppo di capability senza riprogettare il processo che la userà. In pratica questo viene inquadrato con un Discovery Sprint (da CHF 6'000): la nuova implementazione viene costruita e collegata al processo interessato in 1-2 giorni, non come progetto di integrazione separato con un proprio giro di budget.

Il che risponde alla domanda che ogni valutatore tecnico fa nei primi dieci minuti, quindi vale la pena dirlo chiaramente:

{yourcompany}os sostituisce il mio ERP? No. Il vostro ERP, CRM, la posta e gli strumenti specialistici restano dove sono, e le persone che li usano continuano a usarli. {yourcompany}os si collega a essi come implementazioni e orchestra i passaggi tra loro. È uno strato di orchestrazione accanto al vostro ERP, non un concorrente.

Strato 3: il modello di dati, schema aperto, senza login

Lo schema dietro {yourcompany}os è pubblicato come Pragmatic Data Contract, consultabile su schema.pragmaticbim.ch senza alcun account. Potete ispezionare classi, relazioni e release versionate prima di integrare o impegnarvi in qualsiasi cosa, l'opposto di un modello di dati che vedete solo dopo una chiamata commerciale.

Perché questo conta per voi, non per noi:

• Il significato viaggia tra gli strumenti. Entità come progetti, spazi, requisiti, modifiche e oggetti di processo condividono una URI di schema pubblica stabile e relazioni a grafo, così lo stesso progetto significa la stessa cosa in {yourcompany}os, in iterthink e in qualunque cosa costruita sul contratto, invece di essere ricodificato come colonne proprietarie in ogni sistema.
• Potete migliorarlo. Lo schema vive su GitHub come Pragmatic BIM Data Contract. Aprite issue, proponete entità, inviate pull request. Se il vostro settore ha bisogno di un concetto che manca, non state aspettando la roadmap privata di un fornitore.
• L'uscita è ispezionabile, non teorica. Poiché lo schema è pubblico e versionato, potete verificarlo prima di impegnarvi, pianificare un percorso di migrazione ed esportare contro una versione che potete fissare. Sapete in anticipo cosa sono strutturalmente "i vostri dati", invece di scoprirlo durante una controversia contrattuale.

Tutti i dettagli in Schema aperto invece di un database scatola nera. Una precisazione utile: questo non sostituisce IFC. IFC resta il formato di scambio, e lo schema è un contratto orientato al workflow posato sopra, così le applicazioni possono interrogare, validare e automatizzare senza riderivare ogni volta la logica IFC.

Come interagiscono i tre strati: un caso seguito passo per passo

Prendiamo l'evento dell'apertura, "viene creato un nuovo progetto", e seguiamolo attraverso i tre strati.

1. Il processo parte. La definizione Crea progetto inizia e assegna nome e identità del progetto. Definito una volta, in BPMN, e invariato qualunque strumento ci sia dietro.
2. Raggiunge il passaggio di registrazione nell'ERP. Quel passaggio dichiara una dipendenza dal gruppo di capability "ERP / contabilità", non da un fornitore specifico.
3. L'implementazione configurata lo risolve. Se la vostra implementazione per quel gruppo è bexio, il passaggio si esegue contro l'API di bexio. Puntate il gruppo altrove e lo stesso passaggio si risolve diversamente, con la definizione di processo intatta.
4. Il risultato viene scritto contro lo schema aperto. L'entità progetto, la sua identità e le sue relazioni sono persistite come classi del contratto pubblicato invece che come una riga opaca in una tabella proprietaria, così ogni altro prodotto e integrazione su quello schema può indirizzare lo stesso progetto nello stesso modo.
5. Configurazione e chiusura continuano sulla stessa spina dorsale. Ogni sottoprocesso risolve i gruppi di capability che gli servono (archiviazione per i documenti, posta per le notifiche) continuando a riferirsi all'unica identità di progetto creata al passaggio 1.

Confrontatelo con la versione che probabilmente gestite oggi, dove il passaggio 1 è una persona che digita un nome in cinque posti e i passaggi da 2 a 5 sono un thread di chat. Nulla in questo percorso lega il processo a un fornitore, e nulla nasconde i dati prodotti dietro un login. Ogni strato può cambiare senza trascinare gli altri.

Perché gli strati sono separati così

La struttura è deliberatamente l'inverso di una piattaforma a ontologia chiusa. Un sistema come Palantir Foundry tiene la sua ontologia proprietaria, perché l'ontologia è il lock-in. {yourcompany}os pubblica lo schema apertamente e tratta le vostre definizioni di processo, non lo schema, come ciò che possedete e perfezionate. Il vostro vantaggio competitivo non è mai stato il modello di dati; è il modo in cui la vostra azienda funziona davvero. Il confronto completo, comprese le differenze di prezzo e di modello di erogazione, è in Come {yourcompany}os porta il modello Palantir alle PMI.

FAQ

{yourcompany}os sostituisce il mio ERP?
No. Il vostro ERP (per esempio SAP o bexio) resta al suo posto come una implementazione dietro il gruppo di capability "ERP". {yourcompany}os orchestra i passaggi attorno a esso e non assume le funzioni dell'ERP.

Dobbiamo migrare dati o riformare le persone prima di iniziare?
No. È proprio il punto di essere uno strato invece di una piattaforma. I dati restano nei sistemi che li possiedono, e le attività vengono consegnate nella posta e nell'archivio che le persone già usano, ed è per questo che un primo processo può andare in produzione in 1-2 giorni.

Posso ospitarlo in autonomia o sulla mia infrastruttura?
L'hosting svizzero è la modalità operativa predefinita. Poiché lo schema è pubblico e versionato, potete ispezionare e pianificare la portabilità dei dati indipendentemente dal luogo di hosting.

Cosa succede ai nostri dati se andiamo via?
Poiché il modello di dati è pubblicato e versionato invece che proprietario, esportate contro uno schema che già capite e avete verificato, invece di negoziare un formato di export a posteriori.

In cosa è diverso da un iPaaS come n8n o Zapier?
Gli strumenti iPaaS sono forti sulle connessioni di breve durata tra applicazioni ma si indeboliscono quando un processo acquisisce fasi, sottoprocessi e governance, perché il "workflow" e il "processo" sono lo stesso oggetto usa e getta. {yourcompany}os mantiene il processo come definizione durevole e versionata e le integrazioni come implementazioni sostituibili separatamente al di sotto.

Dov'è la fonte di verità dello schema?
schema.pragmaticbim.ch per il riferimento aggiornato e gli snapshot versionati, con il contratto sottostante mantenuto apertamente su GitHub come Pragmatic BIM Data Contract.

E se un sistema che usiamo non ha ancora un'implementazione?
Una nuova implementazione può essere aggiunta per quel gruppo di capability senza riprogettare il processo che ne dipende, incluso il collegamento del vostro LLM come implementazione BYO per il gruppo IA. Questo viene inquadrato con un Discovery Sprint (da CHF 6'000, 1-2 giorni), lo stesso meccanismo con cui va live un primo processo.