Il cambiamento continuo è una costante nella vita delle imprese. Le tecniche utilizzate per la business analysis devono basarsi sul presupposto che le regole di business cambieranno molto rapidamente
La migliore soluzione di business è quella che si rivolge al cambiamento, rendendolo sempre più favorevole alle persone che devono prendere le decisioni e agli analisti che devono produrre i dati sui quali quelle decisioni verranno prese.
Ma quali solo le altre questioni che le tecniche di business analysis dovrebbero affrontare oggi?
Oltre ai continui cambiamenti vi sono:
- Acquisire, gestire e mantenere il know-how aziendale.
- Favorire una governance aziendale più efficace.
- Rendere la conformità (alle regole di business, ovviamente) meno faticosa.
Nessuna di queste sfide è gestita adeguatamente dai tipi di sistemi informativi fin qui realizzati, e le pratiche attuali probabilmente si perdono fino al 90% di tutti gli aspetti importanti nella gestione del business.
Definizione di regole di business
Una regola di business è un criterio utilizzato per guidare i comportamenti operativi di business, formare le valutazioni operative di business o prendere decisioni operative. Le regole di business riguardano solo indirettamente la struttura o il comportamento dei sistemi. Qualunque attività ha bisogno di regole di business anche se non ha alcun software.
L’allineamento
Spesso tutti si chiedono: «Come superare il gap tra il business e l’IT»? Ma questa è la domanda sbagliata. Certamente l’intenzione è quella di superare tale gap, ma se la questione è posta così, implica che la soluzione sarà organizzativa.
Invece, la chiave per una soluzione efficace è nell’architettura: utilizzando l’approccio architetturale giusto, le questioni organizzative si aggiusteranno da sole, in un modo o nell’altro. Quindi la domanda è: «Come allineare le operazioni di business con la strategia di business»?
A essere sinceri, la maggior parte dei business analyst aziendali non hanno una statura sufficiente nelle loro organizzazioni per realizzare soluzioni a livello enterprise e l’esperienza suggerisce che può essere saggio adottare misure a passi più piccoli (si badi bene non a piccoli passi, ma solo più piccoli). E così la questione viene ricondotta a un equivalente più realizzabile e su scala ridotta. Ma come si fa per allineare le capacità di business con le strategie per risolvere i problemi di business? Si troverà che il successo a quel livello di allineamento è sufficientemente fruttuoso (e impegnativo!).
Capacità di business
La capacità di business – o business capability – non consiste in un sistema applicativo, database, insieme di casi d’uso, architettura enterprise o qualsiasi altro oggetto IT. La sua progettazione e realizzazione potrebbero dipendere da alcune o da tutte queste cose, ma questa è un’altra faccenda.
Invece, una capacità di business viene creata come una soluzione di business a un problema operativo di business. Tale soluzione e i problemi che questa affronta hanno una portata (cioè confini delimitati) che possono essere identificati in termini di quali elementi di business la compongono. La soluzione di business è inizialmente sviluppata ed espressa come strategia di business, cioè quello che chiameremmo Policy Charter o lista delle policy.
Il business model che è creato con la business analysis è l’architettura di business per la capacità di business, cioè un progetto che consente alle persone di business e ai business analyst di impegnarsi in una discussione su ciò che deve essere creato, gestito, amministrato, modificato e interrotto. Sviluppare una soluzione di business utilizzando un business model non implica necessariamente lo sviluppo di software, ma se lo sviluppo software ne deriva (e di solito accade), allora il business model fornisce una solida base di partenza. Perciò, la nostra definizione di capacità di business si riduce a questo: ciò che l’azienda deve conoscere ed essere in grado di fare per mettere in pratica la strategia di business.
Abbiamo continuato a utilizzare “business” come un attributo: soluzione di business, problema di business, capacità di business, business model, strategia di business, regole di business, e così via. Ma lo si fa anche nella pratica, e questo costituisce un’ulteriore testimonianza del fatto che la nostra attenzione è sempre sulle faccende di business, e non sui sistemi o sull’IT. Quando parliamo di business, intendiamo proprio quello, e facciamo sul serio.
I principi di base
Qualcuno avrà notato che prestiamo molta attenzione a come (e quando) fare domande. Da come si fanno le domande molto spesso dipendono le risposte e questo fa davvero la differenza. Ed è sempre una buona base di partenza mettere in discussione le domande!
Nella creazione di un business model, anche noi facciamo molta attenzione a non usare mai il linguaggio IT per parlare con le persone di business, in quanto la terminologia IT fornisce un motivo semplice e comprensibile per abbandonare le discussioni di business. Ma non solo. Un business model ha a che fare con le cose reali e deve essere sempre rappresentato usando termini che gli uomini di business userebbero in maniera naturale.
Buona regola è evitare tutti i termini del linguaggio IT, anche se non è facile, in quanto molti termini familiari assumono lo sviluppo di sistemi software. Un esempio è utilizzare “caso”, un termine che ha avuto origine dall’IT e che implica un sistema. Ma nello sviluppo dei business model non c’è bisogno di questi termini (!). Ecco qui un punto correlato: esistono “utenti” solo se si sta pensando di costruire un sistema IT, quindi è bene evitare questo termine. In un contesto di business, gli uomini di business non sono “utenti’”, sono i protagonisti della commedia quotidiana del business. E per questo abbiamo sempre scelto di vederli!
Ronald Ross è presidente e co-fondatore di Rule Business Solutions, dove sviluppa e applica la metodologia IPSspeak, che comprende RuleSpeak, DecisionSpeak e TableSpeak. Riconosciuto a livello mondiale come il “padre delle regole di business”, è autore di dieci opere, tra cui: “Business Rule Concepts: Getting to the Point of Knowledge”, (quarta edizione, 2013), “Building Business Solutions: Business Analysis with Business Rules”, con Gladys S.W. Lam (2011), “Principles of the Business Rule Approach”, (Addison- Wesley, 2003). È inoltre executive editor di www.BRCommunity.com, Business Rules Journal e Chair della Business Rules Forum Conference.
Ronald Ross, insieme a Gladys S.W. Lam, presenterà a Roma per Technology Transfer il seminario “Business Analysis with Business Rules” dal 26 al 27 maggio 2014.
