NOT business as usual, please
This is the seventh in our series of articles that consider why so many transformation initiatives fail and, more importantly, what can you do to improve your chances of success. Last week we considered the project and programme management capability required to manage and co-ordinate the various activities and tasks involved in transformation. This week we look at the capability you need within your leadership team to design the people, process and technology solutions that will define your future state.
What Is Solution Design?
Solution design encompasses all aspects of your future operation; your operating model, team capability, organisation structure, processes and systems. It places uncommon demands on your leadership team to imagine a future state, unencumbered by the present day. The solutions they design need to deliver your vision, strategic objectives and business case benefits, all within the constraints of your agreed design principles. These solutions must also work in the real world and work together as an integrated whole. Functional teams and their customers need to buy in to new ways of working and adopt the change. Functional leaders who have been successful in managing ‘business as usual’ can often find the demands of designing solutions challenging and may need additional support.
Before entering implementation, with its pressures to decide and act quickly, we highly recommend providing opportunities for your team to visit other organisations to see alternate ways of working, to learn and to stimulate new ideas. Group training and coaching sessions on problem solving, innovation and ‘design thinking’ can also help people make the shift from an operational to an ‘architectural’ mindset. Individuals and teams need to have high levels of collaboration, active listening, influencing, resilience and empathy. Identifying and addressing any gaps you have in these critical ‘soft skills’ will pay dividends further down the road.
Key areas to focus on during the scoping phase are the design of your current and future state data architecture. Clarity on where data is mastered today, its quality, availability, accuracy, integrity, and consistency, and how these will change in the new world, are critical to success. This is true whether you’re implementing new systems or not.
If you are changing your systems landscape, then clarity on your target systems architecture and any steps along the way will have a material impact on the complexity, risk, cost and timeline of the technical aspects of your transformation.
Who’s In Charge?
Your IT function should have data and systems architects that can support this work. However, if you are implementing any of the Tier 1 ERP Systems (Oracle Cloud ERP, SAP S/4HANA & SuccessFactors or Workday) it’s worth ensuring your IT team have adequate capability and experience in integrating cloud products with your on-premises systems (Oracle eBS, Peoplesoft, JDEdwards, SAP R3 etc.) and/or integrating multiple cloud solutions.
A well-constructed Target Operating Model is a prerequisite to successful functional transformation. Organisations tend to grow organically over time. Decisions made for perfectly sensible reasons may not make so much sense a few years down the line. Inconsistencies can creep in and the demands of the business can change. Tackling your operating model design during the scoping phase of your transformation provides a solid foundation for your business case and will inform the design of future processes and systems. Target Operating Model design should be an integral part of the programme rather than an afterthought or an org chart exercise to drive headcount reductions.
When it comes to process design, the approach during scoping depends on whether you are implementing new technology and whether that technology is cloud based. If you are planning on purchasing new on premises systems or updating your current ‘on prem’ system, then the approach to process design is the same. You should go to a detailed level of design which lays out process swim lanes and individual process steps prior to engaging a system integrator and starting implementation.
However, if you plan to implement a new cloud Software-As-A-Service (SAAS) solution, the approach is different. Modern SAAS solutions come pre-configured with good practice business processes. You can configure the system based on your Target Operating Model (defining who can initiate, approve and transact various processes) but the processes themselves are dictated by the system.
You still need to carry out end-to-end process design during scoping a SAAS implementation, but it should be carried out at a higher level (typically ‘Level 2’ from a process mapping perspective). Designing detailed swim lane-level processes becomes an unnecessary and redundant step during scoping. Any detailed process designs will nearly always get revised during implementation due to predefined system functionality. Spending time on detailed process design can also be counter-productive as it takes time away from more pressing matters, such as preparing for change and designing your Target Operating Model, data and system architecture etc.
Next week it’s crunch time, the culmination of all your hard work in scoping out this transformation, time to present your business case.
Can’t wait until next week? For your full 10 point Transformation Scoping Checklist click here.
This article on Solution Design Capability covers the ninth of ten critical success factors in scoping a functional transformation programme. Other articles in this series include:
- The first article covering the first three points from our scoping checklist, namely Sponsorship, Problem Definition and Preparing for Change
- The second article focuses on Requirements Gathering and the importance of looking beyond technology
- Governance and Decision Making is the topic of the third article and the financial impact of governance that breaks down
- We cover Vision, Objectives and Design Principles in our fourth article
- Our fifth article looks at the Methodology and Approach used for transformation and the difference between a project, programme and portfolio
- The need for highly effective Programme Management Capability is described in our sixth article
Read Next
Transformation Checklist #10: Business Case
Where the rubber hits the road So you’re sponsoring a transformation programme and you and your team have spent the past six months setting up governance, understanding what needs to change, gathering requirements, selecting [...]
Transformation Checklist #8: Programme management capability
This is the sixth in our series of articles that consider why so many transformation initiatives fail and, more importantly, what can you do to improve your chances of success. Last week we looked [...]
Transformation Checklist #7: Methodology and approach
Why do so many transformation initiatives fail and, more importantly, what can you do to improve your chances of success? This is the fifth in our series of articles that seek to answer these [...]
Transformation Checklist #6: Vision, objectives and design principles
Strategic objectives, design principles and dangerous deviations So many aspects of functional transformation are unknown and unknowable when you begin. By their nature these programmes are disruptive, often formed in response to existential threats [...]
Transformation Checklist #5: Governance and decision making
Destructive forces, burn rates and protecting scope There are three mistakes you can make in defining the governance structure of your functional transformation: Holding too much decision making at the top of the structure [...]
Transformation Checklist #4: Requirements gathering: beyond technology
Welcome to the second in a series of articles that seek to answer the question of why so many transformation initiatives fail and provide practical guidance for success. Many transformation programmes mean changes to [...]