Risposta.

Le regole aziendali sono norme formali o informali stabilite dall'azienda che definiscono il modo di operare, prendere decisioni, effettuare calcoli, comunicare e gestire le informazioni.

L'analista aziendale identifica, analizza e documenta queste regole per garantire che il sistema o il processo futuro sia conforme ai requisiti aziendali e alle normative. Le regole possono essere sia semplici (ad esempio, «lo sconto è riservato solo ai clienti abituali») sia complesse («l'accumulo automatico di bonus avviene solo al soddisfacimento di una serie di condizioni»).

Una descrizione corretta delle regole aziendali garantisce:

• La corrispondenza della logica aziendale del sistema con i processi reali.
• La coerenza dei requisiti tra diversi sistemi e reparti.
• La semplificazione della modernizzazione, test e supporto del software.

Caratteristiche chiave:

• Non tutti i requisiti sono regole aziendali. Alcuni sono limitazioni di implementazione o integrazione.
• Le regole aziendali cambiano spesso, quindi è importante estrarle dal codice e mantenerle nella documentazione.
• Il linguaggio delle formulazioni deve essere chiaro e comprensibile sia per il business che per i tecnici.

Domande insidiose.

Le regole aziendali sono sempre le stesse delle esigenze aziendali?

No, le esigenze aziendali definiscono l'obiettivo da raggiungere, mentre le regole aziendali sono limitazioni o modi per raggiungere tale obiettivo. Ad esempio, un requisito può essere «aumentare le vendite del 10%», mentre una regola aziendale può essere «offrire uno sconto non superiore al 5% ai nuovi clienti».

È possibile implementare la logica aziendale senza analizzare e formalizzare le regole aziendali?

No, poiché regole non formalizzate portano a ambiguità, errori nell'automazione dei processi e violazione delle normative aziendali.

Dove devono essere memorizzate le regole aziendali: solo nel documento di requisiti o anche nel codice del sistema?

La descrizione delle regole aziendali deve essere contenuta sia nella documentazione di progetto (ad esempio, nei requisiti o in un registro delle regole) sia riflessa nella logica aziendale del sistema, ma la principale fonte deve essere il documento, non il codice.

Errori comuni e anti-pattern

• Formulazione delle regole aziendali in termini troppo generali o vaghi
• Duplicazione delle regole aziendali in diverse sezioni della documentazione
• Dettaglio insufficiente, quando una regola copre involontariamente diversi casi
• Lasciare le regole aziendali «per default» senza una descrizione esplicita (silent knowledge)

Esempio dalla vita reale

Caso negativo:

• Nel progetto di automazione delle richieste di prestito, i manager hanno duplicato le regole aziendali solo verbalmente, senza rifletterle nella specifica, e le hanno spiegate verbalmente a diversi sviluppatori — risultando in 3 varianti diverse di implementazione di uno stesso scenario. Vantaggi: Lancio rapido dell'MVP; minimizzazione dei tempi di approvazione. Svantaggi: Discrepanza della logica in diversi scenari, problemi con l'automazione, conflitto tra i reparti.

Caso positivo:

• Per la richiesta di approvazione dei prestiti, l'analista aziendale ha redatto un registro delle regole aziendali per tutti i tipi di richieste, concordato con il legale e l'IT. L'implementazione ha richiesto più tempo, tuttavia le regole erano chiare per tutti. Vantaggi: Chiarezza della logica aziendale, minimizzazione degli errori nell'automazione. Svantaggi: Maggiore tempo speso per la preparazione della documentazione iniziale.