Business Process Improvement – 6 stages to improving your business

Business Process, Improvement, Objectives, Value

This quick guide provides a summary of what is a business process, the 6 stages to implementing improvements and a discussion of how software can play a part in the optimisation.  This is intended for business owners, IT managers and those who are interested in how software development can play a part in improving their business.

What are we defining as a business process?

Wikipedia defines a business process as:

‘A business process or business method is a collection of related, structured activities or tasks that in a specific sequence produces a service or product (serves a particular business goal) for a particular customer or customers.’

Summarising that in more natural language a business process is a logically linked series of tasks that when grouped together form a sequence – this sequence together completes an essential (hopefully) output/outcome for your business.  Examples of business processes include:

Hire to Fire – Employee processes

Procure to Manufacture – everything to buy and produce any products you sell

Order Fulfilment – the process of taking a confirmed order through to fulfilling that order

Next we briefly touch on the key stages in optimising a business process.

Stage 1 – documenting as-is

Understanding what your business processes are today is a critical step in the process, quite often what you think are the steps/tasks for a specific process our clients are often surprised when spending time to document that the actual process differs.  As any process typically involves different people, different systems and a variable time-period these introduce uncertainty and variations in the process.

This stage requires you to take some time to document what the current process is, but don’t be too ambitious with the scope (until you are more comfortable with the process) – keep the business process you are documenting small to start with.  Whether you focus on the use of a mobile app or the interaction of your clients on your website and the subsequent process – keep it simple.

Next don’t get hung up on how you capture the as-is business process, the key is to get started, get something on paper that you can understand and work with and keep updating.  A simple flow diagram is usually the easiest for most (and is the core of a lot of software development design) people to start with – consider the following for each task:

  1. The task itself
  2. Who should complete
  3. What do they require to start, complete and pass on
  4. Any decisions required

Once you have written that down, share it with a wider audience (ideally those who are involved in the process day to day) in order to ensure its complete and valid.  Don’t be tempted to involve everyone or start the optimisation process – keep the number of people involved to the lowest number and focus on As-Is!

Stage 2- defining goals

The second stage is for you to think about what you are trying to achieve, often you will be reading this as you already have some concerns that things could be better.  Perhaps you need to increase sales, reduce costs or simply justify why somebody should change the way they do things in your organisation – now is the time to list some measurable objectives.

Make your goals measurable, realistic and proportional to your ambition for change (we will discuss this more later but setting unrealistic goals will mean you will surely either fail to achieve the change or you will fail to secure support).  If you want to reduce the time taken on producing quotes, improve the number of quotes accepted or reduce the cost spent on creating a quote now is the time to understand what the current metrics are (what are you trying to improve on).

I find this serves two purposes, firstly it ensures we have a target to achieve/beat and more importantly it challenges you to think about the business process, its true costs and whether your expectation (of the time taken, the cost etc) is actually aligned with reality (as often a lack of understanding can fuel a desire to change – driven more from a need to control over a need to improve).

Stage 3 – identify optimisations

After we have defined our goals we can now re-evaluate the process to see where we might make a small change to have a big difference – this can be difficult as thinking differently isn’t easy for anyone (especially if they have followed this process perhaps for years).  Start looking at the overall process – just because you do it this way – should it be done this way?  Do you need to do this process at all?  Are there any industry/online examples of other processes that you might be able to compare with?

Hopefully you have determined that the process is required and that perhaps there are some areas that need to be improved.  Next is to focus on each task – is the right person completing this task (asking a software developer to test software will work – but how effective it is and it is the best use of that resource at that cost etc)?  Are they taking longer than they should?  Is there un-necessary duplication or documentation adding additional time or worse wasted time (any process where there are loops between people to gather information can often be optimised – introducing a system to capture the information early on in the process once will be the key here).

For each of the optimisations list the following:

  1. Who is impacted
  2. How big is the change to the humans involved?
  3. How big is the change to any systems involved?
  4. What is the cost benefit (number of times per week/month, amount of time wasted, cost of that time = cost benefit per week/month)
  5. Is there an appetite for change (just because it’s a good idea doesn’t mean you should do it – there might be legal or human factors which mean it isn’t worth the effort)

Stage 4 – define to-be

Hopefully the easier part now – using the same modelling method to write up our process we now write up/document the to-be business process in the same way.  This serves to explain the proposed changes to a wider audience and seek their buy in/acceptance – as any change is only successful if it’s well communicated and managed.  You should be clear in any changes, who is impacted and what the possible business benefits are – remember to ‘sell’ the benefits to those employees impacted demonstrating how it will improve their work rather than remove their work (people by their nature like to control their work and the power that provides – you need to demonstrate this reduces the no business value tasks to be replaced by business value tasks).

Stage 5 – define transition steps

Depending on the process you have defined there will either be a lot of change or a few small changes, this stage we break up the changes into logical steps.  My suggestion is to start with the low hanging fruit – typically those that impact the least people/systems and would receive the least opinion if they were changed.  The very fact you start with these will demonstrate that change is possible, it can be productive, and it warms people to the idea that not all change is bad.

Remember to group each step in a logical way and define small steps – ideally no more than 6 months to implement the change.  Take a note of any budgetary requirements (for software development, consultancy etc) and timings to ensure its timed with the lows of the business (avoid end of year, peak sales seasons, holiday periods etc) to ensure you have a realistic chunk of change to be implemented in one step.

Stage 6 – implementation and change management

Now you have secured any budget, communicated the change and gained a clear mandate from any management to ensure any change is driven through the business.  Defining a clear plan to implement the change is the secret here – communicate the change early, communicate clearly and repeat messages over a sustained period.  Those who are directly impacted by the change should have the most attention, and ideally a member of each impacted team should have a stakeholder involved in the project.  The stakeholder is there to represent the views of their team, ensure key messages are taken back to the team and more importantly foster acceptance of the change within the team (as it is delivered by a known and trusted source).  The news is littered with failed projects that either haven’t been managed well or although technically brilliant the deployment or change management around the deployment has been handled poorly.

As a software development company, we take pride in the fact we focus on business process improvements, delivering a great value solution and also supporting you and your business in ensuring the solution lands well within your organisation.  Personally having supported numerous projects to deliver into companies organisations where change isn’t always welcomed – I am aware of the on the ground challenges that can be faced (deploying a new mobile solution to drivers across Europe, implementing a new warehouse management system and centralising a procurement process which centralised control of procurement from local procurement managers are some of the real world examples I refer to when considering clients change).

Summary

Business process optimisation like any process can be viewed as extremely complex or really simple, there is no doubt that the benefits of understanding your business processes (taking time away from running the business to ensuring its working well for example) will yield value.  Whether you identify the need to update an existing computer system, introduce some new software development or perhaps a mobile app to streamline your operations defining the objectives via a business process will contribute to a successful project.  OK – so as a software development company we are focussed on that in our examples in this blog but the same is true for any optimisation (not necessarily system based) – reducing the steps in a manual process, allocating tasks to a cheaper resource (or perhaps a remote/external resource) will mean more time/budget to spend on those value add tasks.

The author – Ryan Bishop has spent over 20 years supporting clients in delivering software to help drive business change and business optimisation, having worked for clients such as Danske Bank, Staples, Carlsberg and AstraZeneca he is an experienced business consultant with an Enterprise Architecture qualification (TOGAF), Project Management Qualifications (PRINCE2) and a down to earth and practical approach to solutions.

For a no obligation discussion with Ryan kindly contact the team today.

Posted on