Il business problem statement è una di quelle tecniche che descrive le ragioni di un’iniziativa ICT in termini pratici di business. È la descrizione di un problema attualmente esistente che deve essere affrontato e fornisce il contesto per i problemi che saranno affrontati.
Le dichiarazioni del problema possono essere descritte in una singola dichiarazione seguita da un esempio reale per enfatizzare il problema. Quando si sviluppa una comprensione dei problemi da risolvere, pensare attraverso le sette grandi aree mostrate di seguito.
Esempi sono dati per ogni categoria.
Le categorie delle dichiarazioni dei problemi aziendali
1. Strategia
- Povero allineamento con gli obiettivi di business.
- Le iniziative non sono attualmente allineate ad una visione globale.
- Attuazione silente dei progetti.
2. Servizio / Prodotti
- Impedimento alla fornitura del servizio a causa del recupero intempestivo delle informazioni.
- Lenta reattività nel coinvolgere i lead di vendita a causa del recupero intempestivo delle informazioni.
- Alto livello di resi di prodotti a causa di errori commessi sugli ordini di vendita.
3. Persone
- Formazione inadeguata del personale e/o mancanza di capacità del personale di supportare aree del business che sperimentano colli di bottiglia.
- Ruoli e responsabilità non adeguatamente definiti creano confusione e scarsa reattività alle richieste operative.
- Effettuazione di servizi scadenti a causa di problemi di capacità e formazione del personale.
4. Processi
- Miriadi di processi e applicazioni aziendali duplicati.
- Esecuzione manuale intensiva a causa della gestione fisica dei documenti, delle spedizioni e del coordinamento manuale degli eventi.
- Doppio inserimento dei dati e mantenimento manuale dei dati in fogli di calcolo o database personali.
5. Applicazioni
- Funzionalità poco sviluppate a causa di una definizione inadeguata dei requisiti aziendali e funzionali.
- Funzionalità obsolete causate da un clima aziendale in costante evoluzione.
- Poco o nessun supporto applicativo a causa di software proprietario o ridondante.
6. Informazioni
- Informazioni non strutturate e contenuti memorizzati su vari dispositivi che rendono la ricerca e il recupero molto difficili.
- Nessun metadato allegato alle informazioni che rende difficile la ricerca e il recupero.
- Metodi diversi di codificare gli stessi tipi di set di dati in archivi diversi.
7. Infrastruttura
- Non si sa molto su tutti i sistemi rendendo difficile il coordinamento strategico della manutenzione.
- Applicazioni multiple sono supportate su sistemi multipli creando inutili spese generali di manutenzione per il supporto di sistemi duplicati.
Quando avete capito i problemi, descrivete i rischi associati a ciascuno per sottolineare pienamente i potenziali impatti sul business (es, costi, inefficienze e opportunità perse).
Un esempio di Problem Statement
Di seguito un esempio che descrive un problem statement, una descrizione e un rischio associato per un processo aziendale altamente manuale che può essere facilmente risolto con la tecnologia.
Problem Statement: Elaborazione manuale intensiva dovuta alla manipolazione fisica dei documenti.
Descrizione: I moduli di congedo annuale sono tipicamente compilati dal dipendente, stampati, inviati al Manager/Delegato per l’approvazione, inviati alle Risorse Umane per la verifica e l’inserimento dei dati, scansionati e caricati nell’EDRMS, e quindi inviati a Payroll per il (ri)inserimento dei dati.
Rischio: Questo scenario altamente manuale porta a “colli di bottiglia” nella fornitura del servizio e promuove il rischio di una scarsa risposta organizzativa al business e la perdita di tempo che dovrebbe essere speso per svolgere il core business.
Come sviluppare il tuo Problem Statement
Per sviluppare il problem statement e i rischi associati di un progetto, coinvolgi i manager e gli esperti di materia all’interno delle aree di business rilevanti. Fate loro domande specifiche per ciascuna delle sei categorie descritte sopra per far emergere i dettagli di dove si trovano i problemi. Questa strategia può essere implementata nella fase iniziale del progetto e nelle fasi di analisi, indipendentemente dalla metodologia utilizzata (Agile o Waterfall). E’ utile per sviluppare mandati di progetto e business case.