Not long ago, in an interview, I was asked the following questions. Here are the questions and my responses.
Q: How often do you find that insufficient financial and operations management software represents the weakest link?
Answer: These days, the straight answer to your question is, “Almost never.”
When I started in this business, the PC (personal computer) had just been introduced and I was helping most of my clients move off paper-based systems onto their first computer-based accounting system. I also help with automating other areas like digital estimating systems and more.
Today, however, most business entities we touch have been through at least one ERP implementation. Some have been through several.
That’s why, a few years ago, I created a new acronym for “ERP.” Traditional ERP, I say, was an “Everything Replacement Project”—a wholesale renovation of how an organization works, reports and captures historical data. Most companies today will benefit little—if at all—from another whole renovation.
“The New ERP is ‘Extended Readiness for Profit,’” I tell folks now. We are no longer looking for ways to cut costs (even though that is likely to happen as a side-effect), we are looking for new ways to increase Throughput and profit.
Q: Let’s assume the lack of appropriate financial and operations management software is identified as the weakest link for a given business. How do you “break the constraint”?
Answer: Best practices involve the conscientious and proper application of the ToC (Theory of Constraints) Thinking Processes to reveal precisely which operations and functions need to be augmented in order to:
1. Increase Throughput,
2. Reduce Investment—most commonly, inventories, and
3. Hold the line on Operating Expenses while sustaining significant growth in Throughput in the immediate future.
Any solution that does not offer the proper kind of change in the proper functions will not increase Throughput.
In fact, we even help business leaders pencil-out estimates of the effects on T, I and OE that might stem from a proper implementation of the right technologies. These become their real estimates and the implementation should be accountable to achieve something within the range of the resulting estimates.
The technology selected absolutely must address the precise nature of the constraint(s) identified. Nothing wishy or squishy should be tolerated in the selection of technologies to address constraints. If the technology provides additional benefits, that may be good, but we don’t really care and neither should the management team. The key, however, is to be certain that the new technology doesn’t create any new constraints in the system. (That has been known to happen. We call it “over-automation,” where the workers become servant to the technology, instead of the technology serving them.) Like a medical doctor, the key rule is: First, do no harm.
“Requirements” documents that are nothing more than wish-lists for functionality gathered up department by department ought to be trashed outright. The only valid items in the “Requirements” are those few things—typically, fewer than five—that will directly address the constraint(s) to increasing Throughput.
Do you have a comment, opinion or question? We would like to hear from you. Please leave your comment below.