6 Steps to Improve Your Terribly Complex ERP System
ERPs are humongous.
Your team might be overwhelmed by their complexity. You also have to take into account the technical limitation, legacy code and flows created by different teams, features used by a few users, etc. To solve all those problems you’d need more than 6 principles.
However, these 6 best practices are an essential start to improving your existing ERP system.
1. Involve different experts
The more people are involved in a project, the more difficult yet vital communication becomes. As such, it’s essential that you establish good practices from the get-go.
The first practice you should adopt is having a RACI matrix. It stands for?Responsible, Accountable, Consulted, and Informed. Although this might initially seem excessive, that’s the only way to avoid conflicts and misunderstandings.
Additionally, you can’t become an expert in all the things an ERP does. That’s simply not possible. As such, you need the domain experts’ experience to guide your design, product, and marketing decisions.
Lastly, you need those experts to perform expert walkthroughs, in order to validate your concepts early on. This practice saves hours upon hours of redoing the designs multiple times over.
2. Involve Developers Early
A common mistake is to separate UX and Development processes.
You might think it accelerates or makes things more efficient.
But the cost of conceiving something that just isn’t technologically feasible is high. The cost of coding a bad design is even higher, especially when it comes to ERPs.
Therefore, to make sure you minimize the number of iterations, you must involve developers in the earliest UX activities such as brainstorming.
As long as those meetings are well moderated and structured, you can come up with great ideas and solutions from the whole team.
3. Optimize for different needs
ERPs don’t just entail talking to lots of stakeholders. They also entail talking to lots of (external) users. Naturally, this would result in having multiple personas for just a single ERP module. You can’t afford a generic UX.
A technique that’s proven useful for us is dividing personas into three groups:
领英推荐
You can divide your personas into categories that make sense for your particular case.
4. Balancing between modular and global thinking
Ostensibly, an ERP could be viewed as a conglomerate of separate modules. That’s not the entire truth though. These modules have to work together.
If at some point you decide to allocate different teams to different modules, you’re running the risk of creating something that’s not cohesive.
As such, again, have your team interact together (designers, developers, and other stakeholders). Everything you design and code has to fit together.
Documenting and refining your product decisions is crucial, and a design system is crucial.
5. Documentation & Design Ops
Another byproduct of having large terms is the need for documentation. Otherwise, chaos will have free reign over your design process. The larger the organization, the larger the chaos. As such, you need thorough documentation that’s regularly updated.
A design system can be very helpful to streamline such documentation.
Documentation aside, the larger the team, the harder it is to manage it effectively. Relatively recently a practice of allocating a DesignOps specialist emerged, and we advise utilizing that. ERPs could use DesignOps more than anyone.
6. Productivity beats simplicity
You might be tempted to sacrifice “cluttered” design at the altar of “clean design” and “minimalism”. Isn’t that the ultimate goal of a great product?
This principle, at best, would be situational. Power users often need access to a lot of information at once, so hiding it isn’t a good idea.
On top of that, having a learning curve that in the long run makes users more efficient is also ok. Remember, that organizations stick to ERPs for years, so they definitely have the time they need to fully utilize your product.