Le regole aziendali vengono prima

Recentemente, io e i colleghi stavamo parlando con il capo sviluppatore di software in una grande organizzazione client sui progressi in un importante sforzo di re-engineering lì. La nostra preoccupazione era se i membri del team di progetto potessero rispettare una scadenza di circa nove mesi per la consegna di un prototipo su larga scala. Avevamo appena trascorso diversi mesi intensi lo sviluppo di un modello di business completo, e avevano ancora diversi mesi di progettazione del sistema a sinistra per completare.

Questo capo sviluppatore è molto forte—non uno a impegnarsi a qualsiasi risposta con leggerezza. Per molto tempo, non disse nulla, perso nel pensiero. Infine, guardando i dettagliati diagrammi aziendali intonacati sulle pareti tutt’intorno, ha detto: “Se avessimo già iniziato a programmare, direi che non avevamo alcuna possibilità. Ma dal momento che non abbiamo ancora iniziato a programmare, direi che le probabilità sono piuttosto buone.”

Ho dovuto correre che da più volte nella mia mente prima ho colto il suo significato. “Se avessimo già iniziato a programmare, direi che non avevamo alcuna possibilità.”

Sapevo che pensava che la codifica dell’applicazione stessa sarebbe stata piuttosto dura. Comporterebbe l’utilizzo di un motore di regole, una rete di distribuzione mondiale, interfacce utente grafiche e alcuni middleware significativi.

Stava dicendo che se dovessero risolvere tutti i problemi aziendali durante la codifica, non lo farebbero mai in tempo, o probabilmente mai. Tuttavia, poiché il team di progetto stava affrontando i difficili problemi aziendali in anticipo (inclusa la specifica delle regole aziendali), pensava di avere buone possibilità di completare il codice entro la data di destinazione.

In larga misura, l’approccio delle regole aziendali consiste semplicemente nel porre le domande giuste alle persone giuste. C’è solo un modo per rispettare onestamente una scadenza—e questo è risolvere prima il problema aziendale.

Business-Driven IT

Nei primi giorni di costruzione di sistemi aziendali, il lato business potrebbe essenzialmente sedersi e semplicemente lasciarli accadere. I vantaggi dell’automazione erano così convincenti che non si poteva fare praticamente nulla di male. Ora, per tutti gli scopi pratici, il business e l’IT operano inseparabilmente. Quando si intraprendono progetti, il passo logico sarebbe quindi quello di mettere insieme team di progetto business/IT senza soluzione di continuità e farli seguire un approccio orientato al business per sviluppare i requisiti. Eppure molte aziende sono in nessun posto vicino a farlo oggi.

Troppo spesso, il lato business produce ancora “requisiti” sfocati e mal focalizzati, e il lato IT continua a fare “requisiti” solo una tacca o due sopra la programmazione. Come può essere eliminato questo divario tra professionisti aziendali e professionisti IT nello sviluppo dei requisiti?

La risposta è relativamente semplice. Il business ha bisogno di un approccio organizzato che consente ai professionisti di guidare lo sviluppo dei requisiti. Questo approccio deve fornire una road map che mostra come porre il giusto tipo di domande sulle cose giuste al momento giusto. Ciò che serve è un approccio orientato al business.

Negli approcci di sviluppo tradizionali, di solito si perde molto nella traduzione dei requisiti iniziali al sistema in esecuzione effettivo. Ma la scrittura di una serie di regole di business chiare migliora le comunicazioni tra il lato business e IT, e fornisce un ponte tra l’analisi di business e la progettazione del sistema. L’approccio delle regole aziendali aiuta a colmare il divario tra i requisiti tra il lato business e il lato IT.

Quindi cos’è una regola aziendale? Dal punto di vista aziendale, è una direttiva destinata a influenzare o guidare il comportamento. Le regole aziendali sono letteralmente la conoscenza codificata delle tue pratiche commerciali. Da un punto di vista IT, una regola aziendale è un pezzo atomico di logica di business riutilizzabile.

In un certo senso, tutti sanno quali sono le regole aziendali: sono ciò che guida la tua azienda nell’esecuzione delle sue operazioni quotidiane. Senza regole aziendali, dovresti sempre prendere decisioni al volo, scegliendo tra le alternative caso per caso. Fare le cose in quel modo sarebbe molto lento.

Le regole sono familiari a tutti noi nella vita reale. Giochiamo secondo regole, viviamo sotto un sistema legale basato su un insieme di regole e stabiliamo regole per i nostri figli. Eppure l’idea di regole nei sistemi aziendali è ironicamente estraneo alla maggior parte dei professionisti IT. Diciamo “regole” e molti professionisti IT pensano vagamente ai sistemi esperti o all’intelligenza artificiale. C’è poco riconoscimento di come le regole centrali in realtà sono per le operazioni di base, giorno per giorno del business.

Non a caso, molti lavoratori e dirigenti aziendali sono diventati così ben indottrinati nelle opinioni procedurali per lo sviluppo di requisiti che pensare in termini di regole potrebbe sembrare estraneo o astratto. Praticamente ogni metodologia è colpevole in questo senso, sia per la riprogettazione dei processi aziendali, lo sviluppo di sistemi o la progettazione di software.

Questo è sfortunato per due motivi:

1. Pensare a qualsiasi attività organizzata in termini di regole è in realtà molto naturale. Ad esempio, immagina di provare a spiegare un gioco come scacchi, dama, baseball o calcio senza spiegare le regole.

2. I lavoratori e i manager di Business-side hanno le conoscenze necessarie per creare buone regole.

Regole di esempio

Dai un’occhiata alle regole di esempio che seguono e nota come ogni aspetto del controllo operativo in un sistema aziendale può essere affrontato da regole:

• Restrizioni: un cliente non deve effettuare più di tre ordini urgenti addebitati sul proprio conto di credito.

• Euristica: Un cliente con lo stato preferito dovrebbe avere i suoi ordini riempiti immediatamente.

• Calcoli: il volume annuale degli ordini di un cliente deve essere calcolato come totale delle vendite chiuse durante l’anno fiscale della società.

• Inferenza: un cliente deve essere considerato preferito se il cliente effettua più di cinque ordini superiori a $1.000.

• Tempi: un cliente deve essere archiviato se il cliente non effettua ordini per 36 mesi consecutivi.

• Trigger: “Invia preavviso” deve essere eseguito per un ordine quando l’ordine viene spedito.

Le regole si basano direttamente su termini e fatti. Termini-come cliente, spedizione e fattura—dovrebbero avere una definizione precisa e univoca nel business. Ad esempio, il cliente potrebbe essere definito come: “Un’organizzazione o una singola persona che ha effettuato almeno un ordine pagato nei due anni precedenti.”

I fatti sono dati da frasi semplici e dichiarative che collegano i termini con un verbo o una frase verbale, come “Il cliente effettua l’ordine.”

Un “modello di fatto” è un insieme di dichiarazioni di fatto che descrivono i risultati di un’operazione aziendale. Un modello di fatto dovrebbe servire come un progetto iniziale per un modello di dati, ma il suo scopo primario è quello di acquisire la conoscenza del business in una forma strutturata, distillata dai lavoratori e dai manager che lo possiedono.

Regole essenzialmente aggiungere il senso delle parole deve o non deve ai termini e fatti, come in, “Gli ordini a credito oltre $1.000 non devono essere accettati senza un controllo del credito.”

Le regole dovrebbero essere espresse in un inglese commerciale chiaro, non ambiguo e ben strutturato, a partire da un argomento esplicito. Le regole non dovrebbero avere lanugine e fatti mancanti. Le regole possono essere qualificate, come in ” Una spedizione deve essere assicurata se il valore della spedizione è superiore a $500.”E le regole possono includere criteri di temporizzazione, come in “Uno studente deve essere iscritto ad almeno due corsi entro la chiusura della registrazione.”

Regola Indipendenza

Un business è molto simile a un corpo umano. La struttura della conoscenza (termine e fatto) è come lo scheletro; i processi sono i muscoli potenti; e le regole sono il sistema nervoso che controlla gli altri due. Tutti e tre sono essenziali e correlati. Ma le regole aziendali dovrebbero essere separate dalle altre due. Un principio fondamentale di questo approccio è che le regole sono indipendenti dai processi e dalle procedure. Un vantaggio marginale di tale “indipendenza dalle regole” è un’enorme semplificazione nei processi.

Il risultato è un “processo sottile”, un obiettivo di lunga data di molti professionisti IT. Prendendo le regole fuori dei processi, è possibile produrre processi che sono relativamente semplici e possono essere modificati in caso di necessità.

Nella National Football League, se un gioco non funziona per una squadra, sarà sparito dal suo playbook entro un paio di partite. I giochi sono essenzialmente usa e getta. Allo stesso modo, le imprese hanno bisogno di vedere le proprie procedure come scarti—abbastanza a buon mercato per scartare e sostituire prontamente quando le procedure non funzionano più bene.

Procedure Usa e getta sono un must per il business di essere adattabile e competitivo. Questa idea ingannevolmente semplice-resa possibile dall’approccio business rules—può rivoluzionare il modo in cui il lavoro viene svolto e i sistemi sono progettati.

Ristampato con il permesso di Principles of the Business Rule Approach, di Ronald G. Ross (Addison-Wesley, 2003). Ross è co-fondatore e principale di Business Rule Solutions LLC e redattore esecutivo del sito Web BRCommunity.com.

Modello di fatto della libreria
Questo diagramma mostra un modello di fatto grafico per una libreria. La formulazione della regola si basa direttamente sul modello fact, che è un diagramma di concetti aziendali di base – una struttura di conoscenza. Un modello fact può e deve fornire un modello di primo taglio per il modo in cui i dati saranno eventualmente organizzati in un database. REGOLA: Una tessera della biblioteca può essere utilizzata per controllare un libro solo se il libro è di proprietà di una biblioteca per la quale la tessera è autorizzata.