\u23f1 12 min read<\/p>\n
<\/p>\n
Short answer:<\/strong> Excel in the AI era still holds value \u2014 but only when placed in the right layer. Excel is the best tool for analysis and scenario modeling in the SME “tool triangle” of three layers: SaaS<\/strong> (daily operations) \u2192 Excel\/BI<\/strong> (analysis and asking questions) \u2192 Python\/SQL<\/strong> (bulk automation). AI like Microsoft 365 Copilot speeds up execution but cannot replace judgment on edge cases \u2014 those who know Excel deeply will know exactly where AI is right and where it needs a second check.<\/p>\n<\/div>\n A logistics analyst once shared a meeting with their boss: “We need to learn Python. Excel is a tool from the previous generation.”<\/em><\/p>\n That's not wrong. But it's not accurate enough to guide a decision on what to learn next.<\/p>\n This article doesn't tell you to “keep using Excel” or “drop Excel and learn Python”. It offers a clearer thinking framework to answer that question in the context of your actual work \u2014 in an AI era that is changing how every tool works.<\/p>\n Article contents<\/p>\n “Is Excel still valuable?” is the wrong question. It's like asking “is the hammer still valuable in the age of power drills?” \u2014 the answer depends entirely on whether you're driving nails or boring holes.<\/p>\n <\/p>\n A better question:<\/strong> Which class of problem does Excel solve, and does that class still appear in real work? Looked at that way, the picture is much clearer \u2014 and there's one more dimension few people add: compared to a purpose-built SaaS\/app, where does Excel stand?<\/strong><\/p>\n<\/div>\n When people say “knowing Excel”, they usually mean a set of functions: VLOOKUP, SUMIF, INDEX\/MATCH, Pivot Table. But that's the surface layer.<\/p>\n What Excel forces you to build \u2014 if you use it seriously \u2014 is a specific kind of thinking: decomposing a business problem into verifiable calculation layers.<\/strong><\/p>\n Take a concrete example. A real payroll file is not just “enter hours worked, get salary”. It has to handle, simultaneously: progressive personal income tax across seven brackets, social insurance contributions capped at the salary ceiling, company-specific allowance coefficients, per-department bonus\/penalty rules, and edge conditions for probationary employees. Each variable needs to sit in the right place in the file's architecture, be traceable back to its source, and stay unaffected when someone edits an unrelated cell.<\/p>\n This is the Problem small-scale system design<\/strong>. Those who can solve this problem in Excel will have substantially stronger foundations when moving to Python or SQL \u2014 because they are already used to thinking in data flows, dependency chains, and separation of concerns before knowing the formal names.<\/p>\n<\/div>\n This is what the “Excel vs. modern tools” debate usually overlooks.<\/p>\n When a business moves from Excel to a dedicated HRM, accounting, or inventory system, they are not “upgrading Excel”. They are moving from a flexible thinking tool<\/strong> Switch to operational system with fixed workflows<\/strong>. These are two fundamentally different things.<\/p>\n SaaS is strong where the process is standardized, many people work on a single data source, there is an audit trail, and it scales. Accounting software like MISA or Fast handles journal entries and tax reporting better than any Excel file.<\/p>\n But SaaS has a hard limit: it only answers questions the software designer already thought of.<\/strong><\/p>\n When the boss asks “if we raise prices by 5% but cut credit terms from 60 days to 45, what's the impact on next quarter's cash flow?” \u2014 no software answers that instantly. Because it's a scenario-analysis question, not an operational one. And that's exactly the territory where Excel still has no worthy rival.<\/p>\n <\/p>\n The SME tool triangle<\/strong> is a 3-layer model for small and mid-sized businesses: Operations layer (SaaS\/app)<\/strong> \u2014 managing daily transactions, multi-user, requiring accuracy and consistency. Analysis layer (Excel\/BI)<\/strong> \u2014 pulling data, asking questions, modeling scenarios, making decisions. Automation layer (Python\/SQL\/n8n)<\/strong> \u2014 handling high volume, repetition, connecting multiple data sources.<\/p>\n<\/div>\n In reality, most SMEs run all three layers in parallel \u2014 whether they realize it or not:<\/p>\n The problem for many SMEs today is using Excel for all three layers \u2014 out of convenience, habit, or lack of SaaS budget. The result: Excel files grow bigger, more fragile, and ever more dependent on the one person who understands their structure.<\/p>\n The right answer is not “replace Excel with SaaS”. The right answer is placing each tool in its correct layer.<\/strong><\/p>\n Microsoft 365 Copilot and Google Gemini in Sheets can now write formulas from natural language, spot anomalies in a dataset, summarize trends, and generate pivot tables on demand. This is real acceleration.<\/p>\n But something is happening that few people notice: AI compresses execution time, not judgment time.<\/strong><\/p>\n Testing Copilot on a real payroll file gave an interesting result. The gross salary formula: correct. The social insurance contribution formula at 8%: arithmetically correct. Contextually wrong \u2014 because Copilot didn't know that month applied a reduced rate under Resolution 68, and the phone allowance for that position is not part of the insurance base under the current decree.<\/p>\n AI gets the generic problem right. Your real problem usually has 3-5 edge conditions only insiders know.<\/strong> This creates a widening gap: people who understand Excel deeply use AI to accelerate and know exactly what to re-check. People who only use the surface accept AI output and miss the errors \u2014 because they have no mental model to compare against.<\/p>\n<\/div>\n The same happens with AI-integrated SaaS. Accounting software can now auto-categorize expenses, suggest journal entries, even summarize finances in Vietnamese. But when it miscategorizes \u2014 and it will, on edge cases \u2014 the user needs enough background to spot and fix it. AI works the same way in every tool: it amplifies the capability of people who already have foundations, and creates hidden risk for those who don't.<\/strong><\/p>\n Excel has real structural weaknesses, and understanding them matters more than debating whether Excel is still usable.<\/p>\n But these weaknesses are all problems of usage, not of the tool itself.<\/strong> Version control can be handled through disciplined naming and backup. The scale issue can be addressed by knowing when to switch tools \u2014 or by pulling data from SaaS into Excel for analysis instead of keeping everything in one place.<\/p>\n <\/p>\n Three Excel skill tiers:<\/strong> Tier 1 \u2014 Formula user<\/strong> (knows VLOOKUP, SUMIF, Pivot Table but the file has no architecture, must rebuild when the problem changes). Tier 2 \u2014 Functional user<\/strong> (builds a complete tool for their own use, but others can't maintain it). Tier 3 \u2014 Systems user<\/strong> (builds tools for others to use, sees clearly which layer Excel belongs to in the organization's tool triangle).<\/p>\n<\/div>\n Tier 1 \u2014 Formula user<\/p>\n Knows VLOOKUP, SUM, nested IF, Pivot Tables. But when the problem changes, must rebuild from scratch because the file has no architecture. Problem to solve:<\/strong> learn to design files with separation of concerns \u2014 clearly split data input, calculation layer, and output display.<\/p>\n<\/div>\n Tier 2 \u2014 Functional user<\/p>\n Builds a complete tool for personal use. The file runs well, but others don't understand the structure and can't maintain it. Problem to solve:<\/strong> documentation, naming conventions, Power Query for data transformation separate from formulas \u2014 and more importantly, knowing when to push data to SaaS instead of keeping everything in one file.<\/p>\n<\/div>\n Tier 3 \u2014 Systems user<\/p>\n Builds tools for others, handles edge cases, and sees clearly which layer Excel belongs to in the organization's tool triangle. Next problem:<\/strong> design data flows between layers \u2014 SaaS as source, Excel as analysis layer, Python handling automation when needed.<\/p>\n<\/div>\n Most people at Tier 1 think they're at Tier 2. This is the most common blind spot \u2014 and the reason the question “what to learn next” is usually asked before the question “where am I really” is answered.<\/p>\n Back to that analyst. After more conversation, it turned out their team's problem wasn't that Excel was weak \u2014 it was that they were using Excel for all three layers at once: operations, analysis, and a chunk of manual automation were all living in the same file. Python wouldn't solve that. Layered thinking solves it.<\/strong><\/p>\n The real question isn't Excel, Python, or SaaS. The question is: which layer of problem are you solving, and which tool was designed for that layer?<\/strong><\/p>\n\n
\nAsk the wrong question, and every answer will miss<\/h2>\n
\nWhat Excel actually teaches you<\/h2>\n
\nSaaS is not Excel's competitor \u2014 they solve different problems<\/h2>\n
\n\n
\n \nCriterion<\/th>\n Dedicated SaaS<\/th>\n Excel<\/th>\n<\/tr>\n<\/thead>\n \n Best fit<\/td>\n Running daily transactions<\/td>\n Analysis and scenario modeling<\/td>\n<\/tr>\n \n Multiple Users<\/td>\n \u2705 Good \u2014 permissions, audit trail<\/td>\n \u26a0\ufe0f Hard \u2014 no version control<\/td>\n<\/tr>\n \n Ad-hoc questions<\/td>\n \u274c Limited \u2014 only built-in questions<\/td>\n \u2705 Strong \u2014 ask any question<\/td>\n<\/tr>\n \n Scaling by transaction<\/td>\n \u2705 Good \u2014 handles millions of records<\/td>\n \u26a0\ufe0f Limited \u2014 slow beyond 1M rows<\/td>\n<\/tr>\n \n Deployment cost<\/td>\n High \u2014 SaaS fees + training<\/td>\n Low \u2014 already in Office 365<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\nThe tool triangle: know which tool solves which problem<\/h2>\n
\n\n
\n \nL\u1edbp<\/th>\n Right Tools<\/th>\n Questions this layer answers<\/th>\n<\/tr>\n<\/thead>\n \n Operations<\/td>\n SaaS \u2014 MISA, Fast, HRM, WMS<\/td>\n “What did we sell today? How much stock is left?”<\/td>\n<\/tr>\n \n Analyze<\/td>\n Excel, Power BI, Google Sheets<\/td>\n “If X changes, what happens to Y? What trend is emerging?”<\/td>\n<\/tr>\n \n Automation<\/td>\n Python, SQL, n8n, Make<\/td>\n “How do we make this task run without a person?”<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\nAI inside Excel \u2014 what actually changes<\/h2>\n
\nExcel's real weaknesses<\/h2>\n
\n\n
\n \nWeaknesses<\/th>\n Real-World Risks<\/th>\n How to Handle<\/th>\n<\/tr>\n<\/thead>\n \n No version control<\/td>\n Three people edit at once \u2014 no one knows who changed what, when, or why<\/td>\n Strict naming convention + daily backups; or move to Google Sheets for collaboration<\/td>\n<\/tr>\n \n Doesn't scale with large data<\/td>\n Beyond 1 million rows: slow and unstable<\/td>\n Power Query helps partially; past a threshold, SQL is the right choice<\/td>\n<\/tr>\n \n Logic hidden in formulas<\/td>\n A complex Excel file two years after its creator leaves = a black box with no documentation<\/td>\n Documentation sheet + formula comments + clear naming conventions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
\nThree skill tiers \u2014 where are you?<\/h2>\n
\n