8 minutes read time
“29% increase in productivity when using Salesforce!” (Salesforce on July 10, 2023), “NetSuite simplifies the process of moving goods or materials through an extensive supply chain.” (Netsuite on July 10, 2023). “Benefit from proven business processes for your industry: achieve more profit… work better together… keep improving margins with intelligent automation in all your end-to-end operational processes” (SAP on July 10, 2023). With these kinds of statements, who wouldn’t want to automate? Automation is seen by many companies as the solution and the IT world continues to grow. But does it always deliver what is hoped for? Is it always wise to purchase a standard product? In this blog, we look at where automation began and what thoughts underlie it. Is this always the best solution?
Implementing software often seems to be an end in itself, and sometimes we lose sight of why we automate and why we do it this way. As early as 1776, Adam Smith described in his book The Wealth of Nations that collaborating with someone else and finding a different “division of labour” was much more efficient. Smith explained that we no longer do everything ourselves, but that we have divided the work of baking bread and making meat among different people. By specializing, they could produce more for less. Since the Industrial Revolution, this way of thinking about business processes has become commonplace. As long as we divide things cleverly, we can generate more output and reduce costs per unit. Frederick Winslow Taylor went a step further in his “Principles of Scientific Management” from 1911. He argued that the application of time and motion studies could lead to finding one best and superior method. Not only was it possible to better divide the work, it was even possible to find the superior method that would allow everyone to achieve the highest output individually. This philosophy is still dominant today, especially in the development of software that automates business processes. When automating business processes, it is common to first find a process standard through business analysis and then automate it. Training staff in this single method leads to efficiency. But is this true? Is this approach really applicable everywhere?
“One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head;… Those persons, therefore, could make upwards of forty-eight thousand pins in a day. But if they had all wrought independently, they certainly could not each of them have made twenty, perhaps not one pin in a day…” – Adam Smith in The Wealth of Nations
I have seen this in many software implementations. The company grows, costs increase, and to become scalable, a central information system is implemented. Sometimes it is even the means to achieve integration of business units. After the fact, it is questionable whether this has really been successful. 70 to 90% of acquisitions fail, and the integration of business units is often the cause . By aligning business processes and arriving at a joint data model, the hope is that efficiency will be achieved. This assumption is now even extended across different companies: why would the process in company 1 be different from that in company 2? It requires a belief in an ultimate business process. If you believe in this, you want to use the software that uses it.
The question is whether Taylor’s assumption is correct for every process. Is it really the case that there is one best way to work with each process? If this assumption is incorrect, many investments can be viewed very differently. And if this assumption is incorrect, it can have strongly negative consequences instead of positive ones. If you have automated processes with standard processes, this can bring disadvantages. Take, for example, the adjustment of processes. If it involves human work, adjusting a method is easy. Going back to Adam Smith’s example: simply instructing someone who makes a nail differently changes the method. This may require a little training. However, if it is incorporated into software, we are talking about a more complex change. A new process will have to be designed, the software designed, built, and tested. After this, training and changes in the way of working will still be necessary. If the scale is large enough, it may be worth it. This spreads the costs over more transactions or units, making greater profits possible. If the process that has been automated is complicated or is connected to many other processes, the cost of adjusting these processes will be even higher. Usually, this increases quadratically. Taylor took this into account only to a limited extent: the optimal version had already been found, and employees should not think for themselves. However, in my opinion, the biggest costs are in making the decision. If this is not the case, the biggest cost is the cost of doing nothing. Instead of making a decision in the moment, on the shop floor, in a short discussion between two people, more links are needed and the consideration becomes more complex. This is often already too difficult. Before someone on one of the shop floors that uses this comes to persuade their colleagues and thus make the decision to adjust, many links have passed. The result is that once automated, this process is rarely adjusted. The idea of the employee, or even the manager: the chance that this will lead to a change is simply very small.
But what if there is value in the creativity of humans in the business process? With the advent of AI, this decision is becoming increasingly difficult, but it is still often the creativity of humans that leads to value or even efficiency. The processes that can be done without thinking are more likely to be done by AI or automation. This is a common criticism of Taylor: it assumes that once something can be expressed in tasks, they are only executions that do not require intelligence. Determining when this assumption is correct has become crucial, but it is a consideration that is rarely made consciously. I have seen this especially in departments such as logistics planning or sales. Here it is often thought that products or even teams are the same. And then it must be possible to always do everything the same way and harmonize processes? It is questionable whether these steps lead to efficiency. At a former client’s, these steps sometimes led to bizarre conversations. With only a few employees, a wide variety of products, with many different carriers, and many adjustments per day were planned. How was this possible? The relationships simply didn’t match those of our other clients. Also, not all employees worked the same way. And yet… the output was not bad compared to other parties in the sector. The best choice here was to ensure that the employee had as much freedom as possible and documented as little as possible. We had to adjust our automation needs. A flexibility was required that cannot always be provided. Now I’m not saying that it’s never applicable, but often it’s creative handling of a situation that leads to value. Sometimes it helps to just accept that certain choices or parts of the process are a healthy “black box”. If it takes too long or is too complex to capture certain information or if you notice that employees do not work uniformly: perhaps it is time to doubt Taylor. It may be better to trust the employee and offer them freedom in execution.
Fortunately, the choice is not whether or not to computerize or automate. There are different choices to be made. By keeping the automated processes small, significant gains can already be achieved: adaptation and development are thus smaller. The solution used for automation can also help: choosing a standard solution is usually difficult to adjust and forces the employee into a straitjacket. Customizing the software to your own company or even allowing employees to create it themselves can help. Low-code software or custom software can often make huge differences here: you will have to think more for yourself, but being able to adjust it more easily makes it easier to find further optimizations. Choosing which spectrum each business process falls into is becoming increasingly easy. Specialized partial solutions can be chosen for this.
In conclusion, it is important to assess when evaluating requirements whether there is a process that can be standardized and to what extent. Various software packages claim that using these standard processes has many benefits. Think about the conditions under which this is the case: only if no creativity is required and the choices in the process are entirely standard. Also consider how likely it is that a process can still be changed: in the case of scanning an invoice, this will be limited, but in the case of logistics planning, you want to leave room for optimization by people on the shop floor. Organize accordingly! Make sure you take this into account when determining the requirements.