Defining a solution as a business analyst is all about understanding what the problem is, as we discussed here and what the stakeholder needs are, as discussed here. Once we know what the problem is and what the stakeholders want we can start analyzing the gap between where we are and where we need to be. We call this a gap analysis.
We can carry out a gap analysis in a few ways; we won’t go through them in detail but they are:
- Comparing the As-Is and To-Be models.
- Analyzing Business Activity Models (the stakeholder perspective) and the consensus models (the shared views of all stakeholders). When we analyse these models we can categorize all the processes as: ‘Operating OK’, which will require no immediate action; ‘Some issues’, which will require some action, or we can categorize the process as ‘not in place’ in which case, we require urgent attention. This helps us prioritize our work.
- The changes in the skills required in the new model (current employee skills vs required skills).
- IT system change requirements.
Once we have the gap analysis complete, we need to understand the implications of implementing the proposed changes. To do this, we use the POPIT model. This model helps to provide a holistic view of the overall organizational impact of a change.
- Processes – analysis of the As-Is and To-Be models. It stands to reason that changing an element in a process will probably impact other POPIT elements. For example, changing a process may require additional training, impacting the people aspect.
- Organization – considers the organizational impact of change. McKinseys 7-S model can help us to do this. The model is comprised of structure, systems, strategy, shared values, style, staff & skills. The POPIT model itself, already covers systems, skills and staff so we must consider the remaining 4. Remember, the lines of the McKinsey model are more important than the boxes themselves. So, if the manager has a strategy that doesn’t align with his management style, the strategy will never work. There must be some continuity between the parts of the model.
- People – this involves the communication of changes to staff; skills changes (may also trigger new process definition for roles); recruitment; staff development (appraisals; development plans) and finally motivation & reward – if there is a motivation problem already, adding new skill requirements and changes in their role may not please them and may exacerbate the issue.
- Information Technology – changes to the technology can be modeled using UML (such as ERD/ Class diagrams). IT has become the core area of organizational change and is an area that we must consider to successfully execute the change. Within IT, we should consider: support (future-proofing (e.g. scalability) and familiar technologies (e.g. if your org runs all Linux machines; introducing a single Windows-based system may create a huge support overhead) & accessibility, which includes making using the system as easy as possible, otherwise people will find workarounds or avoid using the system entirely. Finally, we should consider alignment with other business systems – e.g. systems that will consume / send data to this system, we should ensure we have the same data formats to reduce manual re-work or ETL overhead.
Our analysis must consider all of these elements in order to implement successful change. From this analysis, we then develop business requirements which are typically ‘what’ not ‘how’.
The solution we choose must align with the current business architecture in the organization. This is the document that tells us how we should react to changes in the market; encourages re-use between business units and focuses on the areas that deliver most value to the customer. It’s not about the deliverables, it’s about the businesses values & philosophy which should influence all objectives of the business. Any changes proposed must be consistent with business architecture. Think of the architecture as the link between the defined organization strategy & the execution of the strategy,
Business architecture documents have no globally accepted format. But they could include:
- Capabilities – defined by using capability models that at a high level show what the company must do to deliver value to their customers. We group each capability as: strategic (business planning; capital management; policy management); customer facing (distribution; customer service; account management) or supporting (recruitment; procurement; vendor management). Capabilities should be defined in business terms; named as nouns (not verbs); be unique across the entire capability model and must be enabled via value streams. Documenting business capabilities enables organizations to be more agile than those that do not.
- Values – how value is delivered is represented by a value stream. A value stream is a collection of high level linear tasks / stages that create an outcome of value. For example: Initial Inquiry >> Mortgage application >> assessment >> release funds – this does not show who or how the stages are completed.
- Business Units
Content based on study of the BCS Business Analysis course – Business Analysis 3rd Edition (Debra Paul, James Cadle and Donald Yeates).