Design Stage

The Design stage is obviously where the programmes and projects get into the detail of designing the organisation’s future state.  As part of that they also refine and finalise the specifics of the part of the business transformation business case they are charged with delivering.  This future state design must include systems and interfaces as well as processes and organisation, so there is a lot to do, albeit only in the context of the scope of the release.

The work of this stage is normally led by an a combination of key managers and the relevant programme / project managers who draw in others from the organisation as necessary to compete the design.

A typical set of deliverables or products from this stage are:

‘What’ Mapping:

• As-Is / ‘Paper’ To-Be
• Policies & Guidelines
• Gap Analysis (e.g. organising principles)
• Scenario Models
• Systems Selection
• Refined ‘Release’ Business Case(s)

‘How’ Mapping:

• As-Is / ‘System’ To-Be
• Metrics & Reports
• Gap Analysis (e.g. manual v. automated)
• Single Scenario Model (i.e. package configuration & manual workflow specs)
• System(s) Confirmation
• Detailed ‘Release’ Business Case

Detailed Organisation Design:

• Structure
• Roles
• RASCI Matrix
• Pay & Reward
• Measures

Interface(s) Specification

You will recall from the Assess stage that work on the business architecture should only be completed to a particular level of detail.  This is because the detailed design work comes in this stage, and only in the context of the scope of the current release.  As you will now appreciate more fully a key role of the business architecture is to give an overview of the entire business transformation initiative in all its key aspects.

As has been mentioned elsewhere the business architecture was intended to be completed as a somewhat general view of the ‘To-Be’ future state, and was not meant to accomplish any detailed design work. The detail is added in this stage, within the confines of the release scope, with the scope and sequence of earlier releases usually reflecting a higher priority for the organisation than that of later releases.  This is a way of breaking up very large and complex undertakings like business transformation initiatives into smaller and more manageable bites that are also reflective of business priorities.

Another point worthy of making here is the difference between ‘what’ mapping and ‘how’ mapping as used in the descriptions above.  ‘What’ mapping refers to the levels of process decomposition (typically levels 0-3/4) which tends to describe WHAT an organisation does, whereas ‘how’ mapping (typically levels 4+) tends to describe HOW those things are done.

The importance of this distinction is two-fold: (1) the ‘what’ mapping should be a process of confirming, refining and slightly extending what is already in the relevant parts of the business architecture whereas the ‘how’ mapping levels of detail (e.g. work instructions) will normally not yet have been documented anywhere unless you are reusing pre-existing materials;

and (2) ‘what’ mapping can generally be done on paper or electronically (e.g. IDEF diagramming is typically very effective) without too much fear of designing something that is un-implementable.  However, the same cannot be said for ‘how’ mapping, which we believe if done in an area that will be heavily automated (e.g. ERP enabled), should ONLY be undertaken in the context of what the selected software package will support in a ‘vanilla’ configuration…..with perhaps a few exceptions for very important additional features.

Otherwise…..unless it is your explicit intention to create your own bespoke processes via a workflow automation tool; e.g. using an executable BPMN modelling toolset with BPEL outputs……there is the very real chance your detailed ‘how’ design will not be able to be implemented via the straight-forward configuration of a standard software package.

You will then have the painful choice of either having to re-specify the design in a more standard way OR going down the always VERY EXPENSIVE and MUCH MORE CHALLENGING bespoke customised software route……NOT recommended unless it really is a TOP necessity and the payback for the extra effort and pain will justify it!

One further comment is warranted here about ‘As-Is’ mapping.  If the business architecture has been done in a somewhat general ‘To-Be’ future state format, what about the ‘As-Is’ current state mapping indicated earlier?  Well, that depends on whether you want to do it at all.  If you do want to do it the ‘what’ and ‘how’ mapping should include ‘As-Is’ current state mapping as their first steps respectively……which as we have already implied probably has only a limited amount to do with what is to be found in the business architecture.

Many advisers insist that the ‘discovery’ associated with ‘As-Is’ mapping is extremely useful to an organisation and establishes a performance baseline against which to measure ‘To-Be’ improvements (i.e. gap analysis).  We would not dispute either of those claims.  However, we have also increasingly noticed that many organisations, often with a need to cut costs and boost implementation speed…….and given that they ‘know’ they need to improve anyway……are happy to skip ‘As-Is’ mapping altogether and proceed directly to designing the ‘To-Be’ future state.

The main things they sacrifice by making this choice are the learnings associated with seeing what really goes on in the organisation (which is often quite different from what was intended or what executive / senior management believes) and the baseline benchmarks against which to gauge future improvements.  However, in the latter case sufficient information can usually be gathered by other means to adequately (i.e. the data normally won’t be as robust) support business case development and prioritisation decisions without having resort to ‘As-Is’ mapping.

Ideally of course everyone should do ‘As-Is’ mapping……you WILL learn a lot from it…….but if something has to give in the cost and time arena then this is usually one corner that can be cut without representing too great of a risk to future success.

If the content of this webpage makes you feel that being a member of our Biz4ge Network, or a Certified Affiliate within it, would be of benefit to you please Contact Us and we will get in touch by return. Your contact will be treated as confidential and will be at no cost or obligation to you.