A rather cynical friend once told me, “expectations are nothing more than pre-meditated resentments.” In my business, I encounter a lot frustration and resentment around software and technology in general. It recently occurred to me that a great deal of this frustration has been created by unrealistic expectations, a little sales embellishment and dose of stubborn self-centered thinking. Rather than stomping our feet and pointing fingers, we all need to step back and find a healthy balance between want and need.
Case in point. I recently visited the offices of a small distribution software package that I have had a relationship with for many years. In an attempt to reconnect with some former clients and friends in the distribution ranks, I reached out to a few users of this software to ask if they had any challenges I could address during my visit. This seemingly benign act turned into a flurry of emails and multiple conference calls with users who had an “opinion” about their choice in software providers. So much for my nice little visit to see what’s new in their offering. Hey, I’m not blaming these folks for sharing their thoughts. I asked.
As I shared some of these challenges with the provider, I realized that a great deal of this frustration is self-imposed. Don’t get me wrong. I am not out here to belittle or minimize this frustration. These challenges are very real to the companies experiencing them. On the contrary, I see an opportunity to temper this distress by managing our own expectations around these prized business systems.
There are many reasons why companies choose to invest in a new software package. They may feel that they have outgrown the capabilities of their current solution. Perhaps their current provider has been acquired by a larger entity and the package has been scheduled to “sunset”. This is just a nice term to suggest that the acquiring entity will no longer be supporting or developing the package. Migrate to the new platform or you are on your own. Unless we were being forced in the decision to take on a new package, weren’t we just looking to solve a compelling business challenge?
Jumping into a new package can be an exciting time. Slick demos by smooth talking sales people can get our mind racing. The whole pitch is designed to show you how mundane or ordinary your current solution is and get you imagining what if scenarios. Often, we get caught up in the gee whiz factor and fail to ask questions about daily activity. Believe me, software sales people are highly culpable in driving unrealistic expectations. Heck, I have come out of a few software demos thinking I need to buy a distribution company just so I can run this software. After a few sobering breaths, I realize that I am really happy where I am.
One of the biggest sources of frustration for most users is how business processes now differ with the new package. In their frustration, they try to mold and shape the new package to fit how they used to do things. I find it very amusing when a new user requests a boatload of modifications and reports before the “go live” date. They are so busy trying to make the environment familiar and comfortable that they totally forget why they sought out a new solution in the first place. Sounds like a few relationships I had in my 20s, but I digress. Rather than trying to modify the system to fit the company, perhaps the user should take a long look at their business logic and consider changing their processes to fit the software. Remember, most of these packages have hundreds of solid companies using the solution. Are you really smarter than all of them?
I have worked with several companies through the implementation phase of the software relationship. The ones that fair best are those who take the time to learn how to use the solutions as intended. This starts at the very beginning. All software implementations have a training phase. When users take the training seriously, and complete their training assignments, the transitional pain is significantly reduced. When users blow off the training, fail to understand the business logic and get mad when they can’t do what they used to in their old package, the pain goes on for years. When I look at system utilization, the companies that fully embrace the system business logic tend to get a better return on their investment. When users just get proficient enough to try to figure out how to make the system fit their old business logic, return on investment is diminished.
Another source of discontent occurs when companies don’t complete the implementation process. The basics get up and running, but the detail work never quite comes to fruition. Often, new users don’t take time to understand system settings or small parameters. It has been my experience that these minute details, often just one system setting, can make the difference between frustration and satisfaction. It may feel like an accomplishment when that first invoice magically reaches a customer; but don’t take your foot of the gas. There are many miracles left to come.
Finally, if you want to make change, get off the sidelines. Be a contributor to the overall direction of the product. Most software companies offer forums where users can help shape the development of the product. In the old days, we used to call these steering committees; but I suspect that most of the feedback is virtual versus physical. If you want to influence the direction of your solution, put yourself in a position to make suggestions. Attend users’ conferences. Volunteer to beta test new revisions. Mentor other users. In other words, quit lobbing grenades over the fence. Be part of the solution.
Although the ERP is one of the most significant purchases in a business, we have to remember that it is not what drives the business. The people and the culture of an organization dictate the success of failure. Software will not make or break a company. It is merely a tool that will either enhance a good company or inhibit a bad one. Manage your expectations when dealing with the software. Open yourself up to a new business logic or process. Before requesting any modification, ask two very simple questions: 1) What is the purpose? and 2) What business problem does it solve? You might just find yourself realizing that it wasn’t that critical after all. Good luck.
