It is always tempting to push on to design and 'solution' mode when you are starting a new project. This can come at the expense of understanding enough about what currently happens, somthing that can be achieved quickly via a 'current state', or 'as is' analysis.
There are many reasons why a current state analysis is useful, not least because it means that you have investigated today's operating environment. It should (hopefully) capture insights on what is wrong today, how it might be fixed, who is doing it, and how it is done.
Going forwards this gives a baseline to what needs to be achieved and an understanding of the associated 'gap' that exists.
Additional reasons for completing this analysis include:
1. Identifying the potential to reuse current artefacts (i.e. templates / training materials / procedures / etc.)
2. Development of an understanding of where business users' 'thinking and approach' is today so you can begin to construct a message to support the impending changes
3. Bringing visibility of current issues / inefficiencies / reports / stakeholder groups etc.
4. Enabling baselining of current metrics, e.g. efficiency levels, current budget variances, manual workarounds, misaligned processes
5. Providing an overview of source systems & what they do (and do not) provide
6. Giving details of existing infrastructure and identification of gaps with future state expectations
7. Providing details of current roles & responsibilities, gaps that will need to addressed under the new operating model, and proposed organisational design options
8. Bringing an opportunity to understand the scale of the task ahead (i.e. number of users / locations / etc.)
9. Developing a 'bigger picture' view across all relevant business functions
For all this content, it. Is important to remember that you are not actually creating anything new here, rather you are documenting the present situation, so it is vital that you do not spend too much time on this - set yourself a limit of, say two weeks and then stop.
A good way to speed up delivery is to document the current state 'live' in front of your interviewee as you ask questions, otherwise you will spend time re-writing your notes and there is no need for this.
A good principle to follow is essentially to ask similar questions several times to really encourage people to engage - remember you have taken the opportunity to get someone thinking, and they won't give you a second chance, so make the most of it.
Some suggested topics to base your questions on in the completion of your review are as follows:
1. PROCESS DESCRIPTION
2. REASON FOR PROCESS
3. FLOW CHART
3.1 CORE PROCESS
3.2 PROCESS DETAILS
4. PROCESS WALKTHROUGH
5. KEY INPUTS
6. KEY OUTPUTS
7. KEY TASKS
8. CRITICAL SUCCESS FACTORS
9. KEY PERFORMANCE INDICATORS
10. SYSTEMS USED BY PROCESS
11. PROCESS SUPPLIERS
12. PROCESS CUSTOMERS
13. PROCESS FREQUENCY
14. VOLUMES PROCESSED
15. RISKS ASSOCIATED WITH PROCESS FAILURE
16. EXTERNAL INFLUENCES
17. RESOURCES REQUIRED
18. TIME TAKEN
20. MAJOR PROBLEMS WITH PROCESS
21. CURRENT APPROACHES TO COVERING PROBLEMS
22. QUICK WINS / ACTIONS
23. WISH LIST FOR THE FUTURE
24. POSSIBLE IMPROVEMENTS TO PROCESS
25. SYSTEM CONFIGURATION CONSIDERATIONS
26. DATA MIGRATION CONSIDERATIONS
27. INTERFACE CONSIDERATIONS
28. REPORTING CONSIDERATIONS
29. HIGH LEVEL COST-BENEFIT ANALYSIS OF CHANGE
30. LINKS TO OTHER PROCESSES
31. KEY CONTACTS