All Posts From November, 2017

Driving on a Flat Tyre

This is probably not the perfect analogy, because at some point you will have to stop and change the tyre. But it may be if you don’t do it quickly, there will be a much nastier outcome and expense.

However, looking at the things that can bring benefit with minimal effort, it is possible to make progressive incremental changes which buy you time from the outset and start you on the journey to greater savings.  If the majority of your testing is currently manual, then adopting in the first instance technology that makes this less manual (less effort) is an easy and quick win

Read More

The Justification for Making Improvement

If something important on your car needs fixing, you do it.  You don’t really have a choice because you need your car.  It’s the same with your ERP platform, but often senior management don’t look at the details of how you do it, the internal cost of doing it or the fact that the process might be less than ideal with unnecessary risk of failure. It’s been a long time since I’ve done any car maintenance and whilst it might be a lot cheaper for me to do somethings the risk is too great.

Persuading senior management to invest in technology to improve, reduce cost and de-risk should be easy, but in reality, it often takes a good deal of selling.

Read More

Technology in Testing

There are a number of areas in the cycle of managing ERP upgrades where technology can a play a big part, but very often these are not seriously considered because: –

Testing tools are usually in the domain of IT.
The tools on the market are not appropriate for non-technical users.
IT does not need to worry about testing the ERP, that’s th

Read More

Risk vs. Effort

In the ERP world, whether on-premise, private cloud or SaaS cloud the impact of any change is not as clear or easily understood as it might have been in a home-grown application.  The risk is magnified because a third party is making changes to an expensive system, which is critical for running the business, providing changes that we probably did not ask for, that we don’t understand, that may impact other integrated systems and that might have hidden features which can bring business to a standstill.

So, whereas before we relied on quality being determined by effectiveness and good practice across a number of stages in the Software Development Life Cycle (SDLC), the responsibility for quality “Shifts Right” exclusively to the function of testing.  At the same time, the testing team may have been reduced, or more probably the emphasis placed on the business in User Acceptance Testing, that is even further “Right”.

The business users of course are best placed to spot the unwanted features and issues having the best knowledge of how the processes work, but they are not professional testers, they don’t think like testers and are not likely to carry out the most effective quality assurance process.  Not without help anyway.  Do they get that help?  Help in the form of planning, management, analysis, training and technology?  The answer is likely to be at best; “partially”.

Read More