01. The problem often starts with the wrong question
Many technical projects begin with what appears to be a clear requirement. Someone needs a report. Someone wants a new application. Someone suggests using AI. At first glance, the direction seems obvious.
From an engineering perspective, however, these are often proposed solutions rather than clearly defined problems. We still do not know what is actually failing, who is affected, how often it happens or which decisions are delayed because of it.
02. Pause before designing
At the beginning of a project it is tempting to move directly into implementation. If a report is needed, build a report. If someone asks for an application, design the screens. If AI is mentioned, start looking for a suitable model.
In practice, the most valuable step is often the one that feels the least productive: stopping for a moment to understand the process. How does the work actually happen? Where does information originate? When are decisions made? Which activities consume the most time? Where do mistakes occur most often?
03. Operational problems are rarely technical problems
Technology is often the first suspect. A missing system, an integration, a dashboard or an automation feature seems to explain every difficulty.
More often than not, the root cause lies elsewhere. Information is duplicated. Ownership is unclear. Decisions are made too late. The process itself introduces unnecessary complexity. Technology becomes relevant only after we understand what truly needs to change.
04. What we deliberately avoid
We do not begin projects by selecting technologies. We do not automate simply because it is possible. We do not assume that the first requested feature represents the real problem. We do not build functionality simply because it would be interesting to implement.
These shortcuts may accelerate the beginning of a project, but they often slow down its long-term development by solving symptoms instead of causes.
05. From observation to architecture
System architecture should emerge from understanding the process, not from selecting technologies. Before deciding where data belongs or what should be automated, we first need to understand how work is actually performed.
Observe the process
│
▼
Talk to users
│
▼
Identify the problem
│
▼
Understand the cause
│
▼
Design the architecture
│
▼
Implement the solution
│
▼
Measure the outcome Implementation should become the consequence of earlier decisions, not the starting point of the project.
06. The outcome: fewer features, greater clarity
Well-defined problems usually lead to simpler solutions. Not because the project becomes less ambitious, but because unnecessary functionality disappears before it is ever built.
07. Beyond a single industry
This way of thinking is not limited to manufacturing or agriculture. The same principles apply to logistics, maintenance, healthcare, administration or software development.
Every successful project begins with understanding the process before designing the system. The earlier the real problem is identified, the fewer corrections are required during implementation.
LOOKAS Perspective
Technology answers questions. The engineer's job is to ask the right ones first.