My colleague, Duncan Klett, recently wrote the blog titled “Six lessons learned from six failed software implementations.” I completely agree with his lessons learned and recommendations, but I have many of my own! I want to outline two lessons learned from many software implementations that are currently near and dear to my heart.
Reporting…
So many times I work with clients who are scoping out implementation projects and begin asking users what they think they need for reports from the system. The more people who are asked, the more reports make it on the list. Those reports then begin to take on a life of their own. They become a huge wish list of everything users have always wanted.
When it comes time to prototype the reports more light bulbs come on about all the possible reporting capabilities. This is very exciting! (Unless of course you want your project to be completed on-time or on-budget). Even if the project does end up going live with all the great reports (that will solve world hunger and allow users not to actually have to do any work) low and behold the users determine shortly after go live they want to change all the reports. Why would they want to change all the reports, you ask? Well, because they now actually understand how the system really works and they see the actual production data in the reports so they understand it better; then comes the enhancement phase of the project. The enhancement list becomes very long and sometimes costly.
Recommendation: I typically try to encourage clients to keep the list of reports to almost nothing, just regulatory, or reports that are required to run business. And even then, don’t involve a wide group of users, but rather stick with true decision makers. Once the system goes live, do a true reporting project to capture and identify all reports. Have a reporting strategy for the life of the system which allows for users to request new reports or enhancements to existing ones. Have a review board to ensure the requests are valid. Review the reports annually or bi-annually to determine usage of reports and anything not used in the last six months get rid of it. This may seem like basic advice, but why don’t we all follow it?
How do you handle reporting during a project? Do you have any other advice to share? Super Users…
We’ve all heard the term Superuser. Wikipedia defines the term as: “The ‘Superuser’ in enterprise programs (SAP, Oracle) often refers to an individual who is an expert in a module or process within the enterprise system.” I think that is a pretty good definition - Each client I work with discusses having Superusers, however not all client’s actually put a name(s) to that title before a project begins. This could mean failure! If the company cannot define who the Superuser will be in particular business process areas during the implementation then who will actually help define what needs to be implemented, and better yet know what is actually implemented at go live? Post go-live is a nightmare of support because no one actually knows how to use the system and client is reliant upon consultants to teach them; which is both costly and inefficient.
Recommendation: Encourage clients to assign a Superuser(s) to a project before the project starts. That Superuser(s) works hand in hand with the consultants and is preferably dedicated to the project. The Superuser would even do some of the development of the system while the consultant oversees. How better to truly learn and adopt the system that “doing it yourself”? That person should also be the ultimate decision maker as it relates to scope and design of system or be the ONE conduit to that ultimate decision maker. By doing this the client should feel ownership of the system and feel it is “theirs” as there is at least one person who lives and breathes the system.
What experience have you had with Super Users on projects, either positive or negative? Do you have any other advice to share?
Discussions
As a long time Materials Manager, I have seen the transition of ERP systems from basic MRP processing through MRP2, ERP etc right through to current web based releasing and endless other data "feeds" for both suppliers and customers. Modern Materials systems have unleashed a seemingly endless variety of real time data for those hungry for the latest changes in demand, KPI data, etc. Inevitably, there is always at least one "Superuser" who has the uncanny ability to grasp the technical side of today's systems as well as develop reams of data to help them make decisions.
Superusers come in two forms:
Frantic, beligerent people who have a low tolerance for those who can't grasp the technical side of how to create database queries.
Quiet customer service oriented, supplier relationship people yearning for data to help them make the best decisions for the betterment of the company.
Most conscientious materials people know what they want for the end result but don't understand how the system can supply them with the required data. These users end up being Excel experts and best friends with the cycle counters. The intolerant "Superusers" become the higher profile representatives of how the company should proceed with their ERP development.
The answer? As explained in the article, everyone wants data formatted to suit their personal preference. The superuser is actually the Materials Manager, (or similar function) who has to temper the technical solutions with practical need. He/she has to weigh all of the options of system functionality and decide the best course of action.
Leave a Reply