System Thinking: The core of solving business problems with technology
- Problem: Businesses rush to write code before understanding the problem, producing software that solves the wrong thing.
- Solution: Systems thinking — start from analyzing data flow and process, applying three core principles.
- Outcome: Technology serves the business problem, explaining why you need a Delivery Manager, not just a dev team.
Over my years of architecting and managing software projects for the Japanese and Vietnamese markets, I frequently encounter a very common trap: "Premature Solutioning". When a business faces a problem (e.g., data entry takes too long, customers complain about wait times), the first reflex is usually "Let's buy software XYZ" or "Let's hire a dev to code an automation tool". This is precisely where IT projects are most likely to hit a dead end. Instead, what we need is System Thinking.
TL;DR (Executive Summary)
- Problem: Many businesses suffer from "Premature Solutioning", rushing to write code or buy software before truly understanding the core issue, leading to wasted budgets and failed IT projects.
- Solution: Apply System Thinking to analyze the entire data flow and process before coding, focusing on 3 principles: resolving bottlenecks, maintaining a Single Source of Truth, and designing for change.
- Outcome: Build a system that accurately solves business problems with optimized costs. This explains why businesses need a Delivery Manager to bridge business goals and software architecture, rather than just a Dev team.
1. What is System Thinking in software development?
System thinking is not the ability to draw complex server diagrams or memorize Design Patterns. System thinking is the ability to see the entire "flow" of a business process, understand its constituent parts, and predict how the entire machine will react if one link is altered. If you consider a business as a machine:
- The Implementer (Coder): Sees a worn gear and replaces it with a new one.
- The System Architect: Asks "Why did this gear wear out faster than normal? Is the pressure from the main axis misaligned?"
2. Start with the problem, not the Code
A real-world case I handled: A client requested a highly complex Warehouse Management System (WMS) because their warehouse was constantly reporting inventory discrepancies. Previous agencies had quoted massive systems with 3D barcode scanning, IoT, etc. By applying System Thinking to analyze the situation, I realized:
- The problem was not the current software.
- The problem was the physical process: Warehouse staff frequently received goods but didn't immediately store them on shelves; they left them temporarily in the aisles, meaning they couldn't be found during dispatch. The Solution: Instead of rewriting the entire WMS for tens of thousands of dollars, we redesigned the physical warehouse workflow, created a dedicated "Buffer Zone", and added a small module to the existing software to track the "Temporary Storage" status. The problem was solved at 1/5 of the originally estimated cost.
3. Three Core Principles of System Thinking
When approaching any problem, I always follow 3 principles:
Principle 1: Identify the Bottleneck
In a system, the speed of the entire assembly line equals the speed of its slowest link. If you optimize a process that isn't the bottleneck, the overall system won't get any faster. (This is where System Auditing skills are crucial).
Principle 2: Single Source of Truth (SSOT)
Data should only have one source. A customer should have a single unique ID that flows unbroken from Marketing to Sales to Accounting. If your system requires staff to copy data from one tool to another, the system is architecturally broken — this is exactly the human-dependency and data-fragmentation trap I see so often at SMEs.
Principle 3: Design for Change
A good system isn't the one with the most features; it's the system that is easiest to modify when business requirements change. Modular design thinking (decoupling modules) allows businesses to easily swap payment gateways or shipping providers without rebuilding the entire app.
4. Why do businesses need a Delivery Manager instead of just a Dev team?
Having a skilled coding team is necessary, but not sufficient. You need someone capable of "translating" business language into system architecture language, ensuring every line of code written serves the right business objective, and managing operational risks. That is the role of a Delivery Manager. Japanese-standard project management doesn't lie in forcing deadlines, but in the meticulousness of Requirements Analysis and system thinking before execution begins.
Are you struggling with a convoluted process or a software system that isn't delivering expected results? Don't rush to tear it down and rebuild. Submit your system case to me. We can start with an in-depth discussion to find the real "bottleneck" in your system. Or, you can see how I apply this thinking in Real-world Projects.
Nguyen Chau
Delivery Manager / System Architect
14 years of experience delivering architecture and systems for the VN-JP market