Proper business analysis, talent management and why I’m in love with Visio

Proper business analysis is the bit that often gets missed

A lot of business analysis, process engineering and change management tends to fall on people within the company. They don’t necessarily have the right skill sets and their full-time position isn’t always back-filled. A lot of problems can stem from this, when the person who is writing out the specifications hasn’t done it before and doesn’t have capacity to focus on their new role and learn on the job. IFS offers great support in lots of ways, but they won’t do this for you. They won’t map out the process flow of how something should work through the business.

Once the product has been selected, whether that’s IFS or another system, the first step should be thinking about how the business processes work, map out the ‘as is’, and ‘to be’ processes and then share that with your developers – before you start thinking about what customisations you’ll need.

This is the single most important thing for me, write out the new processes for what a business user should be able to do, step by step. This will show you what’s painful and time-consuming for people to do. Then you can find out if the product automates that for you, or if you need modifications.

In an ideal world, the technical consultants would be involved at the business process design stage, to review how to make things work for the business.

Then they can standardise the code, introduce templates, and reduce unnecessary risk and re-work.

Ryan Ibbitson
Senior Developer

Microsoft Visio is wildly under-rated and I’m in love with it

Process mapping can be document-heavy if you get too much into the detail, and that’s why I’ve fallen in love with Visio. When you have the flow diagrams your developers can see the high-level overview and tell you what’s possible, practical and where there are likely to be problems further down the line.

Give developers problems to solve not tasks to complete

Developers tend to be given a task to do rather than a problem to solve, which is fine when the processes have all been mapped and the new processes are really clear. But what you tend to find is things aren’t completely covered from a technical perspective.

So after development begins, design changes become necessary. And then the work starts to loop back around to process mapping, to design and back to technical development. This can become a horrible cycle with workflows going around in circles from the business to development, to test and back to the business, where the business lead is constantly writing new specifications.

An example of this could be a site-specific development, where you only want a customisation to happen on a certain site. The task is given to a developer, and they build that small piece of the process to automate what a business user would do. Then later the developer is tasked with amending this to action for other sites, so they have to start changing something on the original build. You might want a configuration table if it’s a decision point, but it’s no longer a linear process. 

In an ideal world, the technical consultants would be involved at the business process design stage, to review how to make things work for the business. Then they can standardise the code, introduce templates, and reduce unnecessary risk and re-work.

Spreadsheets saved on desktops vs. centralised management tools

From the development perspective, when you’ve done your high-level review of the business process engineering then you’re confident in what specifications will change the system to make it work for the business. Now you’ve got a list of jobs, that’s basically your backlog. The next step is to prioritise it, and this when is you need a centralised tool for managing updates.

There’s plenty of systems for sharing information. DevOps is good but it doesn’t really matter which one, as long as the developers, testers, and project manager have one point of focus. When everyone is working from localised spreadsheets it becomes a big headache to manage competing priorities.

Talent management is an over-looked aspect of IFS ERP implementations

From the business perspective ERP projects aren’t just system implementations, they’re talent development programmes. IFS implementations are hothouses where people can gain five years’ work experience in two, and upskill themselves across a range of IT expertise like business analysis, project management and data analysis.

As the business embeds the new ERP, the balance of where you need people will shift. You’re changing the way the whole organisation works and introducing new sets of business processes across departments. If you’re doing it right, it’s going to mean some roles become redundant and new roles open up. There will be opportunities to retain your talent by lifting them up the value chain. Offering people on your ERP project clear career pathways means you decrease the risk of losing them.

Sometimes people will take a role on the IFS implementation because they’re interested in IT as a career change, so they do the job for six months and leave. This can cause setbacks when the project is continuing for another two years. Your IFS project team, with all their new skills and knowledge, are just as valuable to the business as the ERP.