Why IT systems don't work the way we dream

With each new implementation of an IT system (hereinafter referred to as “the system”), businesses may put forward very different requirements and expectations regarding the work and processes that the system should support.
And here, the following factors are not always taken into account:

1. What existing capabilities does the chosen system have? 

This situation often has several sides: ● The business does not understand the alternatives or does not want to consider the existing capabilities because they differ from the current reality. ● Consultants involved in the implementation are not aware of all the system’s capabilities and/or cannot convey to the business that the standard functionality allows for a different way of working.
As a result – rejection of the specific system, or significant modifications requiring additional resources. 

2. For what purpose is the system being implemented?

Usually, the business response is accounting, business process formation, automation, reporting for analyzing the current situation, planning, and forecasting. And this is where hidden “traps” come to the forefront: ● For accounting purposes, all documents and operations must be recorded timely and discretely, not “aggregated at the end of the month.” ● For business process formation, they must actually be followed – surprisingly enough 😉. ● For automation, established processes and complete, up-to-date data are required; otherwise, constant errors are inevitable. ● High-quality reporting sets fairly high requirements for processes and data quality, and without fulfilling the previous points, this is unlikely. ● Any planning must be based on something more or less real data – previous orders, contracts, forecast data. ● Forecasting, in turn, can rely on accumulated high-quality data from past periods and trends based on them, considering variable factors. 

By the way, this often reveals a misunderstanding of the difference between a plan and a forecast. Due to the specifics of common terminology, everything is usually called a “plan.” 
For example: 
● Plan in SAP TM – when a client orders transportation of 10,000 tons of cargo for the next year. ● Forecast in SAP TM – when a carrier company, based on last year’s shipments, assumes that this year they will also transport 10,000 tons.

For the first case, there are concrete grounds, while for the second – only expectations. And that is precisely why SAP TM is suitable for planning, but for forecasting either another solution is required, or significant enhancements to the current functionality.

3. Do the system’s capabilities meet the expectations and wishes of the business? And do they really need it?

Here we encounter a dichotomy between business requirements and system functionality. For example, a typical situation during SAP TM implementation is when the business wants to see a document such as a Work Order, which should include several Trips. But this is a manifestation of analog, pre-digital, paper-based logic.

Previously, it was easier to keep transport records on paper, and therefore such grouping methods were used. For a digital system, however, this approach brings no advantages. The established practice is: one transportation – one document. Because the system will not lose a piece of paper if there are many, it will not get confused by numerous documents, and it will not get tired of creating an additional one.

4. To what extent do the stated requirements and the real needs of the business coincide?  

Often, driven by enthusiasm, the business wants everything at once. But it is not ready for this now and not ready to undergo transformation. A typical example in SAP TM is the absence of high-quality reference data for business partners, addresses, vehicle classification, a structured map, and clear transportation rules. Sometimes the starting point is simply: “load more – drive farther.” 

5. Is the business ready to additionally invest in developing functionality that is missing in the standard solution?

Everyone wants the “out-of-the-box” solution to cover all needs. Usually, the following happens: during system selection, the business claims to have standard transportation processes, but already at the SAP TM implementation stage, “certain peculiarities” emerge. It is advisable, whenever possible, to think about this in advance. Or to develop a prioritization – what is needed first, and what can be added later. As practice shows, part of what was considered “absolutely necessary” often turns out never to be needed. 😊

Different Expectations from the System 

Before and during the implementation of any system, there may be different expectations of the outcome. And depending on a person’s position, these expectations can differ significantly – even be completely opposite. 
Let’s take a closer look. For company owners and C-level managers, the goals of implementation (using SAP Transportation Management as an example) may include: 
● Increasing company capitalization (through the fact of implementing a well-known, proven IT system). ● Systematizing business processes in accordance with Best Practices. ● Establishing stable business processes and a working system that is less dependent on employee characteristics, their competencies, and the factor of human error. ● Transparent and understandable end-to-end processes. ● Clear and complete analytics generated without “manual” report preparation and without the subjective factor of a business analyst. 

For middle managers and regular employees, the goals may be different: 

And the most interesting point – these wishes may be incompatible with each other, especially when it comes to the goals of C-level executives versus regular users.

Different Ways of Using the System 

 Any IT system can be used in several ways, depending on needs and understanding: 

Depending on the readiness of the business, systems can be used for one or several of the above purposes. They do not contradict each other but rather flow from one another and complement each other. 

Finding the Most Appropriate Way of Use  

Any system, like a microscope, can be used in different ways: for its intended purpose or as a hammer. And the second way is not always wrong. Although, objectively, buying something complex and expensive for that purpose is a strange decision.

Therefore, when choosing a system for implementation and defining how it will be used, it is important to consider the context. A small company with three simple operations per day does not need a complex system. For a slightly larger number of operations, full accounting and calculation of work results can be used. But complex and expensive automation and a forecasting/planning module will most likely be inappropriate.

An exception may be a situation where a company wants to consistently implement system functionality, moving from simple to complex. And the example of SAP TM can be quite illustrative here: first implement only Order Management for recording operations, then transportation tracking, next automatic planning with the optimizer, then use BNL (Business Network for Logistics) for interaction with carriers. And, as a logical continuation, implement dispute management functionality.

Only after all this can one think about attempting to optimize the transport network based on historical data or trying to forecast future shipments. But that would already be the “microscope-hammer” scenario. 

Evolution in System Usage  

With ideal, steady company growth in both quality and quantity, the business can go through all evolutionary stages of using information systems – from recording operations in Excel to automatic transportation planning in SAP TM. This is driven by company expansion and the geometric increase in the number of operations, which cannot be adequately controlled by a proportional increase in personnel.

At that point, the company faces a choice: stop growing or use a multiplier in the form of an IT system to increase efficiency. First – to create control over the execution of operations, then – to reduce manual work for specialists and obtain new analytical data for managerial decision-making.

The ceiling of development, theoretically, has no limits, but each subsequent improvement usually costs more and brings less benefit. Therefore, marginal utility decreases noticeably. And the “pain” of transitioning to a new system increases. But unfortunately, this is unavoidable. Because systemic achievements are never gained easily.

Conclusions 

 What will the conclusions be? Probably none. Just know your business, know your business processes, learn about the new capabilities of the system you plan to implement, and don’t try to fit a square peg into a round hole.