Come mantiene gestibili centinaia di automazioni del CRM?

01Il problema di business

Un evento di business richiede di solito il controllo di diverse cose non correlate. Si prenda un account che passa da prospect a cliente:

• Se mancano i dati del contatto principale, avvisare il responsabile: altrimenti ogni successiva email automatica non si rivolge a nessuno.
• Se la regione è stata digitata come abbreviazione di due lettere, espanderla, perché altrimenti la reportistica per paese si frammenta silenziosamente in duplicati.
• Compilare le date di rinnovo a partire dalla durata del contratto, che è di dodici o di ventiquattro mesi.

Non sono alternative. Un singolo account può aver bisogno di tutte e tre, e non hanno nulla a che fare l'una con l'altra. L'istinto è scrivere un unico processo per "l'account diventa cliente" che gestisca tutto quanto, ed è di questo istinto che parla il §2.

Il parco da cui è tratto questo blueprint conta 265 processi distribuiti su sette entità, di cui 113 su una sola entità. Quel numero non è disordine e non è un segnale d'allarme. È ciò che produce la forma del motore quando un'azienda ha tante regole, e la domanda interessante non è come averne di meno, ma come mantenerne leggibili centinaia.

02Perché l'approccio ovvio non funziona

Mettere tutti e tre i controlli in un unico processo

È il malinteso più costoso possibile nel motore dei processi, perché il disegno sembra più ordinato e il guasto è invisibile. Peggiora anche con il successo: più casi copre il processo, più è probabile che un record ne soddisfi diversi e ne riceva uno solo.

Né si può aggirarlo inserendo un nuovo varco a metà catena. Un filtro non può mai essere figlio di un'azione: la forma canonica è trigger, poi filtro, poi azioni, e il motore non accetta un secondo varco appeso alla fine del lavoro del primo. Le condizioni indipendenti non possono quindi essere espresse in alcun modo all'interno di un unico processo. È un fatto strutturale, non una preferenza di stile.

Nomi descrittivi

Chiamare un processo in base a ciò che fa (Invia l'email di benvenuto, Aggiorna la data di rinnovo) è chiaro il primo giorno e inutile in un elenco di duecento, perché l'elenco viene allora ordinato per verbo. Tutto ciò che inizia con Aggiorna… finisce insieme a prescindere da ciò che tocca, e i sei processi che riguardano un dominio si disperdono lungo l'alfabeto. L'elenco lo si legge molto più spesso di qualsiasi singolo nome.

Documentarlo in un foglio di calcolo

Esatto il giorno in cui viene scritto, sbagliato entro un mese, perché il parco cambia nell'interfaccia di amministrazione e il documento no. Tutto ciò che viene mantenuto in parallelo alla cosa che descrive finisce per divergere. Ciò che sopravvive è ciò che vive nel parco stesso, ed è per questo che il nome ha così tanto peso.

03La forma di un processo, e ciò che ne consegue

Tutto in questo blueprint discende da un unico fatto strutturale:

trigger  →  filter  →  actions
              ↑
              exactly one, at the root.
              A filter may never be a child of an action.

Il che significa che un processo può applicare una condizione indipendente. Una seconda condizione richiede un secondo processo, e il modo per arrivarci è un nodo di attivazione di processo, che passa il controllo a un altro processo e porta il proprio filtro. La condizione successiva vive nel passaggio.

Fonte. Centro assistenza Coevera, Automatizer — triggering a process from another process, che presenta lo stesso meccanismo come il modo previsto di costruire: «processi più snelli … concatenati in un flusso di lavoro unificato». Il Process Manager che li elenca è documentato a parte.

Quindi l'esempio del passaggio da prospect a cliente non è un solo processo. È un rilevatore più tre sottoprocessi:

Ogni sottoprocesso valuta la propria condizione in modo indipendente, quindi un account che richiede tutte e tre le correzioni le riceve tutte e tre. È l'unica ragione per cui il parco ha questa forma.

04Il tipo di trigger è un fatto di primo piano

Esistono quattro tipi di trigger, e il tipo determina sia come si arriva a un processo sia come fallisce. Questo appartiene al modo in cui si pensa al parco, non a qualcosa che si scopre aprendo un processo.

05Schemi che mantengono leggibile un parco di grandi dimensioni

Tag per dominio, e un prefisso anche nel nome

Ai processi si possono assegnare dei Tags, e il Process Manager filtra per tag oltre che per proprietario e stato (Automatizer — creating and running processes). Li usi. La ricerca dell'elenco però opera sui nomi, un tag compare solo in una colonna che si sceglie di aggiungere, e non esistono cartelle né una vista documentata delle dipendenze. Metta quindi il dominio anche nel nome, tra parentesi quadre all'inizio:

[Contracts]  Create the renewal record
[Contracts]  Watch the renewal date for changes
[Hygiene]    Normalise country and region codes
[Hygiene]    Flag records whose status contradicts their dates
[Outreach]   Send the scheduled check-in

Un elenco piatto allora si raggruppa da solo quando viene ordinato, una ricerca su un dominio restituisce tutto ciò che lo riguarda, e aggiungere un processo impone la domanda a quale dominio appartiene?, che è ciò che intercetta un duplicato prima che esista.

Il parco esaminato usa circa una dozzina di prefissi, il più grande con venticinque processi e il più piccolo con due. Questa distribuzione è di per sé uno strumento di revisione: venticinque membri sono un dominio che vale la pena leggere per intero, e due sono o un vero caso limite o un incidente di denominazione.

Dia un nome alla catena, non solo al processo

Poiché i sottoprocessi vengono raggiunti perché sono richiamati e non perché osservano qualcosa, l'unico indizio su chi richiama chi è il nome. Un prefisso condiviso più un verbo coerente per il rilevatore, il processo che possiede l'evento, rendono una catena leggibile dal solo elenco. Senza di essi, seguire un evento di business significa aprire processi finché non si trova il chiamante.

Un sottoprocesso serve sia da subroutine sia da strumento di riparazione

Poiché manuale significa richiamabile ed eseguibile, il sottoprocesso costruito per la catena è anche ciò che si esegue a mano quando una data si sposta, un record viene creato fuori ordine o un'automazione è stata disattivata per un pomeriggio. È lo stesso meccanismo del gemello manuale nel Blueprint 010 e della derivazione rieseguibile nel Blueprint 009: non uno schema distinto, ma lo stesso visto da un'altra angolazione. Lo costruisca una volta e farà entrambe le cose, purché mantenga il proprio filtro radice.

Un ramo finale senza corrispondenza che dice qualcosa

Qualsiasi filtro che associa un valore a un esito dovrebbe terminare con un ramo che intercetta tutto ciò che i rami precedenti non hanno intercettato, la cui azione è avvisare qualcuno. Con una semantica in cui vince la prima corrispondenza, un valore non riconosciuto imbocca altrimenti qualunque percorso di ripiego esista e non produce alcun errore. È l'assicurazione più economica disponibile in un parco di queste dimensioni.

06Limiti e compromessi

La scomposizione descritta nel §3 è obbligatoria. Le conseguenze qui sotto non lo sono: derivano da una seconda lacuna: la piattaforma segnala quando un processo viene eseguito, non come si compone il parco. Il Process Manager ha una colonna Activity (24 hours) e statistiche di esecuzione fino a 14 giorni, e ogni processo conserva un Activity Log delle sue esecuzioni (Process Manager). Con le notifiche attive, il proprietario viene avvisato quando un processo ancora collegato a un altro viene eliminato o disattivato (triggering a process from another process). Nessuna vista documentata mostra invece che cosa richiama un dato processo, o che cosa smetterebbe di essere raggiunto senza di esso. Dove metà dei processi di un'entità viene raggiunta solo perché richiamata, quel grafo delle chiamate mancante è la parte costosa.

Nulla viene eliminato, quindi le cose vengono rinominate

Il rimedio è una convenzione, non uno strumento: dismettere significa prima disattivare, poi rinominare, infine eliminare in una data scritta nel nome. Un processo contrassegnato come inutilizzato che scatta ancora è peggio di entrambi gli stati presi da soli, perché il nome dice alla persona successiva di ignorare qualcosa che sta lavorando attivamente.

I duplicati si accumulano anno dopo anno

Tutto ciò che ha un anno nella propria logica tende a essere copiato anziché esteso ogni gennaio, e la copia più vecchia non viene mai dismessa. Questo parco contiene diverse famiglie di questo tipo, in cui due processi svolgono in gran parte lo stesso lavoro su intervalli di anni diversi. Ciascuno era la modifica minima corretta al momento; insieme sono due punti da aggiornare e un testa o croce su quale sia stato effettivamente eseguito.

I processi pianificati collidono, e nulla la avvisa

Gli orari pianificati vengono scelti uno alla volta, senza una vista di ciò che è già pianificato. In questo parco tre processi giornalieri non correlati girano alla stessa ora, e altri sono distanziati di cinque e di venticinque minuti.

Pianificare alla stessa ora non è di per sé un difetto. Lo diventa quando due di essi toccano gli stessi record, perché tra di essi non c'è alcuna garanzia di ordinamento né alcuna transazione attorno a nessuno dei due: quale dei due prevalga non è qualcosa che si possa dedurre dalla configurazione. Tenga un unico elenco degli orari pianificati e dei relativi responsabili, e distanzi tutto ciò che condivide un insieme di record.

Un sottoprocesso orfano non si distingue da uno funzionante

È il modo di fallire introdotto dal modello a composizione. Un sottoprocesso viene raggiunto solo quando è richiamato. Se il suo chiamante viene disattivato, il proprietario può ricevere un avviso, purché le notifiche siano attive; se il chiamante viene riscritto in modo da non richiamarlo più, non viene segnalato nulla. In entrambi i casi il sottoprocesso continua ad apparire come ogni altro processo attivo nell'elenco, con un'attività silenziosa come in una settimana tranquilla. Il suo filtro è ancora corretto. Nulla lo consulta.

È anche l'unica forma di processo morto di cui si possa davvero dimostrare la morte, perché la chiamata si trova nella definizione del chiamante stesso. Questo rende il tracciamento delle catene di chiamata la verifica di maggior valore nel §7, e l'unico modo per ripulire un parco con cognizione di causa anziché affidandosi al coraggio.

I processi personali sono una categoria reale

I parchi di queste dimensioni contengono processi con il prefisso delle iniziali di qualcuno: strumenti personali costruiti per la routine di una persona. Funzionano, vengono usati e sono invisibili a tutti gli altri. Dia loro un prefisso condiviso e metta nel nome ciò che fanno, perché l'alternativa è che restino senza responsabile il giorno in cui quella persona cambia ruolo.

Che cosa non abbiamo verificato

Le affermazioni strutturali (un solo filtro alla radice, un filtro mai figlio di un'azione, i quattro tipi di trigger, il nodo di passaggio che porta il proprio filtro) sono lette dallo schema dell'API e da definizioni di processi estratte dall'interfaccia di amministrazione. Il comportamento dei rami di un filtro, in cui vince la prima corrispondenza, e i dati sul parco citati in tutto il testo provengono dalla gestione di questa implementazione.

Non abbiamo testato l'attivazione e la disattivazione massive in base a uno schema di nome, né se la piattaforma offra una vista del grafo delle chiamate; la documentazione del Process Manager non descrive né l'una né l'altra. Le pratiche descritte presuppongono che nessuna delle due esista, perché è così che questo parco viene gestito nella pratica, ma il mancato utilizzo non prova l'assenza. Se sta definendo convenzioni per un nuovo spazio, controlli l'interfaccia di amministrazione attuale prima di impegnarsi a compensare a mano.

07Verifica

Questa è la verifica per un parco che non ha costruito lei, e funziona dall'esterno. Tutta si basa sulla lettura dell'elenco dei processi anziché sull'apertura dei processi uno alla volta.

• Raggruppi per prefisso del nome e guardi quelli che non ne hanno. I processi senza prefisso sono di solito gli incidenti: aggiunti di fretta, mai più rivisti. Conti anche i prefissi distinti: più di una quindicina significa che lo schema ha smesso di essere uno schema.
• Controlli la presenza del singolare e del plurale dello stesso prefisso, e dello stesso dominio scritto in due modi. È il guasto silenzioso più comune di una convenzione di denominazione e bastano trenta secondi per trovarlo.
• Raggruppi i processi pianificati per ora del giorno. Tutto ciò che condivide un'ora merita un'occhiata; tutto ciò che condivide un'ora e un insieme di record merita una correzione.
• Cerchi nei nomi not used, obsolete, old, temp, copy e le iniziali personali. Poi verifichi se ciascuno è effettivamente disattivato. Lo scarto tra "nominato come morto" e "spento" è il punto in cui questa verifica si ripaga.
• Segua le catene di chiamata. Per ogni processo con trigger manuale, trovi che cosa lo richiama. Quelli che nulla richiama sono davvero morti, ed è l'unico tipo di processo morto che si possa dimostrare, perché la chiamata vive nella definizione del chiamante anziché in una deduzione. Lo faccia prima di qualsiasi altra cosa se ha ereditato il parco.
• Confronti il numero di processi manuali con quelli attivati da record. Una quota elevata di processi manuali in un parco maturo è prevista e sana: è il livello di composizione. Ciò che conta è se ciascuno ha un chiamante. Un numero elevato di processi manuali più processi orfani è il segnale che una catena è stata riscritta e le sue parti lasciate indietro.
• Controlli l'indipendenza di ogni filtro a più rami. Dove i rami rappresentano alternative (uno stato che assume uno di quattro valori), un solo processo è corretto. Dove rappresentano condizioni che potrebbero essere tutte vere contemporaneamente, il fatto che vinca la prima corrispondenza significa che se ne applicherà sempre una sola, e le altre vanno estratte in sottoprocessi. È la verifica che individua l'errore del §2 in un parco costruito da qualcun altro.
• Provi a enunciare lo scopo di ogni processo in una frase. Quelli per cui non ci riesce sono quelli che portano più di una responsabilità, e sono i candidati a essere suddivisi: non perché siano rotti, ma perché sono quelli che nessuno oserà modificare in seguito.

Che cosa segnalerebbe una regressione: un nuovo processo senza prefisso, o con un prefisso che non è nell'elenco concordato; un processo con trigger manuale senza chiamante; un filtro a più rami i cui rami sono condizioni indipendenti anziché alternative; un processo indicato come dismesso che è ancora attivo; due processi i cui nomi differiscono solo per un anno; un processo pianificato aggiunto in un'ora che ne ha già uno che tocca gli stessi record.

Blueprint correlati

• Blueprint 010 — lo schema a diramazione nella pratica: una modifica di data scritta come quattro processi anziché uno, e perché ciascuno richiede un gemello manuale.
• Blueprint 009 — perché i processi attivati dalle modifiche falliscono in silenzio, che cosa fa un processo pianificato con input obsoleti e la derivazione rieseguibile che ripara entrambi.
• Blueprint 003 — la domanda che evita in partenza la crescita del parco: se occorra davvero costruire qualcosa.