In this exclusive article, fashion industry expert and implementation advisor Nancy Winslow sets out some high-level guidelines for choosing your ERP solution and adhering to best practices when the time comes to put theory into action.
Software implementation needs to make sense for the users as well as the organization. It’s all too easy for executives and project managers to pick a software solution, choose an implementation partner, and begin the arduous process of putting it all to work – all withoutever consulting the people who will actually use the system, day in and day out.
While it isn’t always practical (or desirable) to explain the minutiae of selection and implementation to team members at every level, it can be extremely beneficial to follow in the footsteps of other retailers and brands who have done it right. And in most cases, you’ll find that those companies followed a set of common, proven best practices throughout their ERP projects.
The term “best practice” itself can turn some people off, since they assume that these are broad guidelines designed to apply to automotive and aerospace as much as apparel. In fact, in my experience best practices vary dramatically from industry to industry, and whether you build catalytic convertors or cardigans, adopting those that are specific to your industry can often make the difference between success and failure.
I’ll examine more of these apparel-specific best practices in a future article, but it’s important to remember when we talk about them that they are not limited to choosing and implementing a solution. There are numerous examples where the adoption of best practices has helped to ease or even enable the kind of whole-business transition that a far-reaching ERP project will bring about.
If I might focus on the actual selection and implementation themselves for a the time being, though, I’ve identified what I consider to be three major best practices that should inform all software projects – ERP, PLM, SCM, or any other acronym you care to name.
The first begins before you have even begun the process of buying a solution. Your company needs to understand what we call its “as-is” processes – the way that things are done today. Analysing these is not something you should sugar-coat; it can be tempting to paint things as rosier than they are, but in practice this serves nobody’s interests, since an ERP project is the perfect opportunity to be entirely candid about your challenges and weak points. After all, if everything is working smoothly as it is, why are you preparing for a sweeping, enterprise-level change in the first place? Instead, use this chance to examine your processes and ways of working with absolute honesty and clarity, since this is the only way you will be able to establish an accurate baseline upon which to improve.
Secondly, the practitioners overseeing your project should identify where the problems rest with those “as-is” processes, and use this information to create an idealised “to-be”, which will show the desired end point for your enterprise transformation. The gulf between the way things are today and the way you want them to be is what we at WhichERP refer to as the “process maturity gap”, and it’s precisely this that you’re looking to bridge with your new solution.
As you can see, these first two best practice examples are designed to do one thing: provide you with a framework within which you can make an informed decision as to how you will go about choosing and implementing an ERP solution. Even a cursory glance at our supplier listings will show that the market is extremely crowded, and taking these proven preparatory steps can give you the foothold you need when it comes to narrowing down a manageable shortlist and picking a supplier who can cater to your unique requirements.
Finally – and this is closely tied to the first two best practices – it’s essential to understand the benefits your organisation is hoping to receive from the project. This is typically covered by a return on investment (ROI) analysis and key performance indicators, but it’s important that you realise where that sort of ROI information comes from. Without a thorough understanding of the way things are and the way you want them to be, is it possible to examine how effective the transition was? I don’t believe so, and best practice suggests that properly quantifying both as-is and to-be processes is absolutely key to understanding the effectiveness of implementations.
By way of example, a key performance indicator (KPI) might be identified as the need to minimise the number of staff members required to handle a refund, or to reduce the number of days taken to process a refund from five to one. Generally speaking, KPIs are designed to help you identify precisely what is to be measured between your as-is and to-be processes, and are then used to visually catalogue those improvements and tie them to a dollar (or pound) value.
All too often, we see retailers and brands jumping straight into the ERP market and attempting to weigh solutions against one another without ever really understanding what’s driven them to do so in the first place. I know of a company who wanted to buy an ERP solution to improve efficiency, but who also still manually keyed in production orders: this company had a clearly visible task that was adding days of work (not to mention inaccuracy and error correction) to the product lifecycle, but chose instead to look outside the immediate issues to try and solve their problems.
As I’m sure you’ll agree, this is not the recipe for an effective implementation. It’s absolutely vital that retailers and brands determine where the bottlenecks and pain points exist in their current processes before they turn to any large software solution to patch the cracks. It may not be possible or practical to remedy all of these issues prior to shopping for ERP, but the important distinction is that doing so actually enables you to make an informed decision, and select a solution that will fix the problems you know you have, rather than the ones you choose to ignore.
With this kind of information in-hand, the practitioners in charge of the project (either internal team members or impartial, unbiased, advisors) can create a project plan and begin to prioritise process targets for improvement based on objective data. Those priorities can be a mixture of “quick wins” (i.e. those processes with the largest potential for rapid improvement and time to value) and pain points, which might be those processes already identified as causing the most delay or additional work.
The goal of an effective project plan is use the information gleaned from these three best practices to streamline the entire process of implementation, mitigating or eliminating steps that do not add value, and that additionally waste time, cost money, and do not benefit either the organisation or the end user.
Software – whether it’s ERP or PLM – should always be chosen and implemented safe in the knowledge that it will improve the way a business works. By adhering to best practices right through from introspection to implementation, you can improve your chances of streamlining the right processes, reducing redundancies, and improving the working lives of not just your organisation, but also the people within it.
Conversely, ignoring best practices will ultimately only damage your bottom line, and impede the effectiveness of your company’s human capital.