Picture a mid-sized textile company. The owner adds a stock and purchasing module to the existing accounting software. Installation is done, staff training is completed. Six months later, stock counts are still done by hand, invoices are sometimes never entered into the system, and purchase orders keep circulating on paper. The software is running fine. But the way people actually work has not changed. This is what low process maturity looks like in practice.
Process maturity — how consistently, predictably, and measurably a company carries out its work — is what determines whether ERP software delivers real value. Buying the software is only the first step. The company’s own working habits need to align with how the software is designed to operate. A simple question reveals where you stand: ‘Do we do this task the same way every time, or does it depend on who is doing it?’ If the answer is ‘it depends on the person,’ maturity is still low.
Think of process maturity as four steps on a staircase. The first step: the process is not defined at all. Every employee handles the task their own way. Change the person, change the method. The second step: the process is written down, but nobody follows it. There is a procedure sheet somewhere in a drawer. The third step: the process is both documented and actually followed, and the results are measured. You can answer questions like how many invoices were issued on time or how many orders were delayed. The fourth step: the process is measured and actively improved. Last month deliveries were delayed by twenty days; this month it is down to ten. The team is working out how to cut it further.
Now look at your own company. Take your purchasing process. When a material need comes up, what happens next? Does the warehouse worker mention it verbally, or is a written request opened in the system? Are quotes collected, and if so, from how many suppliers? Who approves the order and how? If you can answer these questions clearly, your process is at least defined. If you cannot, no matter how capable your ERP software is, it will not help much. Software can speed up a defined process. It cannot fix an undefined one.
The most practical benefit of measuring maturity is that it shows you where to focus first. In one company, the accounting process might be at the third step while stock management is still stuck at the first. In that case, getting full value from ERP means fixing the stock process before anything else. The software module is open, the data entry screen is ready, but if the right data is not being entered, nothing useful comes out. Incorrect input produces incorrect reports. This is why a maturity assessment belongs at the beginning of any ERP project, not after the problems have already piled up.
For a straightforward self-assessment, try this method. List five core processes in your business: purchasing, stock, sales, accounting, and production planning if applicable. For each one, answer four questions. First: is there a written description of how this process works? Second: do employees actually follow it? Third: is there a measurement that shows how well this process is performing? Fourth: is that measurement used to make the process better over time? Each yes earns one point. Five processes, four questions — twenty points total. If you score below twelve, getting the return you expect from ERP will be an uphill battle. The processes need to be sorted out first.
Run this assessment before you buy ERP software, or run it now if you have already installed it. Either way, the result gives you a clear picture of where to put your energy. Whichever process scores lowest, start there. Sit down with the people who do that work, write out the steps one by one, assign responsibility for each step, and put a simple measurement in place. Skipping this work and jumping straight into software modules is like filling a ledger with numbers that have no meaning behind them. Building process maturity takes time and patience, but it is the only way to make an ERP investment pay off.
This article was originally written in Turkish by Gökhan MERCANOĞLU on May 17, 2004 and has been automatically translated into English and other languages using machine translation.