Having spent nine years in the software solution space for a very niche vertical, I was indoctrinated into the typical software vendor idealology of “one system one solution.” It forced us to push the client to fit their business model into the software. The problem with this model is that it doesn’t take strategic business advantages, six sigma methodology or change management best practices into consideration.We would sell the software, migrate the data, train the client on the software and then simply wish them good luck! Any follow up was a feeble call and a few words of encouragement as they were struggling. The planning phase consisted of looking at their operations and taking extensive notes on both the day-to-day and periodic operations. While it would appear that we were aligning our software with how they do business, it was more to determine what activities we would insist they change to accommodate our software.
So why would a business be okay with this? To some extent, the clients were aware of the process. Most vendors did the exact same thing, which led to it becoming “acceptable.” After we left then they would establish a work-around for the software. The software was close enough to a “perfect fit” solution, so why reinvent the wheel, right?
Software vendors rely on customer feedback for system requirements. Those requirements are need-based from business activities. The software that I trained on and supported was very specific to the industry. The modules followed a typical process flow inherent to the activities of the vertical. Upstarts and third-generation companies liked this as the software was simply a reflection of the ERP they would have had in place anyway. Companies converting from other systems were maintaining vital operations with only minor adjustments. They would then take advantage of the time to clean up their data from the legacy system.
So what’s the problem? Is it that big of a deal? Take what you need out of the system, exploit the pieces that work, ignore what doesn’t. What is the issue? Well, in cases of ERPs, change management and production best practices, success has very little to do with the software. At this point it is strange to me to think of a software package as having any significant contribution to the success of a business. Software packages are a tool to do a job. It would be akin to suggest that a construction company was successful because they had a better bulldozer, or a pharmaceutical company was thriving because they just implemented a new robotics line. Software is a communication and organization tool, not the solution. It is the hammer, not the worker.
The problem amplifies as the company grows. A SaaS package will be great to help mold the business, especially if it is a new company and they are focusing on starting operations instead of strategic forecasting. However, as the company grows, the operations get more complex, cross-functional areas pop up everywhere and I have actually seen innovation stifled because “the software couldn’t do that”. In comes Tier I and II solutions. This is the time to methodically assess current “as-is” processes, discuss “to-be” goals, perform process optimization initiatives, gap analysis and consider independent ERP professionals.
A CEO can’t be blamed for being attracted to an all-in-one business and operations solution. Follow the yellow brick road and you will make money. That is the cry of every software provider. While it may work for some, I’ve learned that there is more to business operations than following the steps. Trade secrets, economic advantages, the strategic market alignment and manufacturing best practice initiatives make the difference between industry dominance, and just struggling to catch up.
At no point will you be able to call the software vendor and tell them to change the software to accommodate your new processes.
At no point should a user not implement a strategic process because the software doesn’t have the capability.
At no point should you be spending quality time on the phone convincing the software provider to incorporate that feature into the software, because they won’t.
I’ve said it myself before…”the system doesn’t do that.”