Process Development for a Fast-Growing Company (#209)
/In this podcast episode, we discuss the process development process within a fast-growing company. Key points made are noted below.
Typical Process Development
As a business grows, you have to keep expanding the number of processes, because the business is becoming more complex all the time. In addition, a process that might have worked fine at a low volume level starts to fall apart as the volume increases. So that’s two separate aspects of process development. Let’s start with adding to the number of processes, and begin with an example.
A small business starts out selling products directly to customers, so it has the basic processes – shipping, billing, payables, and inventory control. Then management decides to add a new type of customer, which is retail chains. The additional process that has to be addressed now is customer returns. This might have been such a tiny issue when there were only direct sales that no one cared about it. Now, the retailers ship back everything they can’t sell, which massively increases the number of returns – maybe by a factor of 10, or 20, or even 50. At this point, management considers product returns to be a major process, and the controller is told to clamp down on it with a system of return authorizations. That’s a real example, by the way. It almost bankrupted a company that I worked for a long time ago.
Inclusion in Strategy Discussions
So how do we find these additional processes early on, before they become problems? There’re a couple of ways. One is to include the controller or CFO in all strategy discussions. This gives you early warning of a potential new process before a business starts branching out into new areas.
Talk to the Staff
Second, talk to the staff. In that example I just gave, the people who knew about it were the receiving staff, who processing pallet loads of returns, and the billing staff, which was processing the credits. They know if there’s a problem before anyone else does, so cultivate contacts throughout the business.
Conduct a Process Review
Third, schedule a process review. Get the accounting staff together maybe once a quarter, and talk about which processes are working, which ones need some adjustment, and in particular which areas need processes.
And if you think processes are really a problem, then bring in a process consultant to keep examining systems all over the company and recommend changes. If the company is growing really fast, a consultant might be the best alternative, since the staff will be too buried with work to spend time on this.
Review for Losses
Another possibility is to dig through your cost variances to figure out why losses are occurring. For example, the engineering manager decides to start changing product configurations. When he does that, some older components in inventory are no longer being used, which means that the inventory obsolescence expense will start to go up. With some digging, you can figure out that some of the inventory is being bypassed by the new product configurations. The logical outcome of all that cost analysis is that an engineering change order system is put in place, where existing stocks are drawn down before a product change is allowed. Unfortunately, that’s an after-the-fact detective control, since the company is already losing money before you can find the problem and install a process to correct it.
Watch the Transaction Volumes
The second aspect of process development is figuring out when to change a process when it’s being buried by transaction volume. A key item is to watch the processing backlog. If you’re maintaining a reasonable staff headcount and the staff is well trained, and yet the processing backlog is still going up, then the process may need to be upgraded. And that doesn’t necessarily mean adding more staff to the existing process.
For example, you have a reasonably good, mid-range payables software package where the payables staff has to manually input each supplier invoice into the system. That may work fine, until the volume of incoming invoices suddenly triples. In this case, the choice may be to add more staff, but you could also look at installing a portal on the company website and requiring suppliers to enter their own invoices into the company’s payables system. Or, install an invoice scanning system that automates data entry.
For both solutions, you need to look at whether the underlying accounting system can incorporate the updates. If it can’t, then you need a whole new accounting system.
And that means that you need to plan ahead to figure out which specific system upgrades will be needed as your transaction volume goes up, and from there, figure out which accounting systems will support those upgrades.
Plan for the Most Appropriate Software Upgrade
What you’ll find is that most of the lower-end systems are largely self-contained, and don’t support those nifty labor-saving features. Which can put a controller or CFO in a bit of a bind. If you assume that growth will be fast, then you need to install an upper-end accounting system right away, before the department is buried with too much work to do a system conversion.
However, if the growth never materializes, then the company will be stuck with a terrifically awesome and amazingly expensive accounting system that it just doesn’t need. So here’s the essential problem: switching to a better accounting system needs to happen during a slack period when there’s time to install it - but there are no slack periods for a fast-growing company, so you have to correctly guess in advance that sales will increase, and install the system before they increase. But it’s hard to make that call when there’s not yet any evidence that sales will increase.
So what do people actually do? They still try to look as far ahead as possible and make the best guess for an early system upgrade, but by the time they get to it, sales will have already taken off, so they pretty much have to bring in a consulting firm to help them with the system conversion. The in-house staff just can’t spare the time to do a conversion correctly.
And in the worst case, there is no advance planning for a system upgrade, so it has to be done in a rush long after it was actually needed, which introduces a greater risk of failures because the new system wasn’t tested properly before it was turned on.