無論是為了節省成本，還是提升營運效率，管理層都難免會考慮數碼轉型、引入 AI，或者更換現有的管理系統。隨之而來的，往往是員工收到一個模糊的指令：「你幫手研究下…」到底這個「研究」背後的真正目標、具體要求和執行方法是什麼？
缺乏明確的方向，不僅令員工感到迷惑，更會導致研究成果永遠停留在紙上，無法落地。不論你是下達指令的管理層，還是負責執行的員工，在項目 (Project) 啟動的第一步，我們其實可以借用傳統銷售中的BANT 法則，將這個模糊的「想法」轉化為精準的「內部需求評估」。
💡 B = Budget預算
在 BANT 銷售法則中，預算指的是客戶口袋裡有多少錢；但在機構內部需求評估（Internal Assessment）中，預算必須重新定義為兩個維度：顯性資金成本（Tangible Financial Cost） 與 隱性資源成本（Intangible Resource Cost）。許多軟件項目在第一步就宣告失敗，正是因為管理層在下達指令時，陷入了這兩個維度的認知盲區。
🔖顯性成本：確立「射程範圍」以避免無效研究
多數機構在叫員工「研究一下某個解決方案」時，往往不願意先透露預算上限。這種先看再說的預算盲測，是機構資源的最大浪費。
- 認知盲區：管理層認為「不設限才能看到最好的方案」，但現實是，市面上同類型的軟件，價格落差可能高達 10 倍。
- 連鎖反應：員工在毫無指引的情況下，可能花數週研究一套年費 100 萬港元的國際頂級系統，並撰寫了精美的評估報告。直到最後審批時，管理層才表明預算只有 30 萬。這導致前期的員工工時、市場調研，全部變成毫無價值的沉沒成本（Sunk Cost）。
- 最佳實踐（Best Practice）：在開始任何研究前，管理層務必給出一個射程範圍（Budget Range）。大型商用系統的定價機制如同裝修工程，通常不公開或涉高度客製化。團隊的首要任務是透過原廠銷售獲取粗略報價（Ballpark Estimate），快速篩選掉不符合預算的方案。
🔖隱性成本：引入 FTE 評估，避免「被 OT」引發的連鎖崩潰
這是軟件項目最常發生的「隱形成本陷阱」。管理層往往只計算購買軟件的投資金額，卻將「員工的執行時間」視為免費。
- 認知盲區：老闆認為「我橫豎都付了這份薪水，員工順便研究一下、順便統籌一下、順便負責一下，不算額外花錢。」
- 組織代價：根據實際營運數據觀察，一個中大型軟件項目在初期的需求評估與市場調查階段，通常需要投入 0.5 至 1 個 FTE（Full-Time Equivalent，全職等量值），且需要持續 1 到 2 個月。如果沒有撥出專責人手，而是強迫現有員工在日常工作之外「被 OT」兼任，機構將面臨兩個後果：
- 因陋就簡的惡性採購：員工因日常工作分身乏術，只能草率看過規格便草草了事。最終買回來的系統無法解決核心痛點，形成資金浪費。
- 核心員工的流失風險：執行項目的巨大壓力常成為壓垮員工的最後一根稻草。當核心員工不敵壓力而離職，項目不僅直接停擺，機構還必須承受人才流失與重新招聘的沉重代價。
💡 A = Authority權責
在 BANT 銷售法則中，尋找 Authority 是為了找出擁有採購決定權的關鍵決策者（Key Decision Maker）。但在機構內部評估中，尋找權責的本質是釐清項目的政治實權與資源推動力。
許多團隊埋頭苦幹研究了幾個月，最後項目卻被擱置，核心原因就是沒有在第一步釐清權責背後的兩大核心邏輯。
🔖財務權責（Financial Ownership）：Follow the Money
要判斷一個軟件項目到底誰是主理人，最直接的方法就是：找出誰是付款的老闆。
- 認知盲區：「CIO叫我研究，CIO就是主理人」。但在現實中，協調者不等於預算承擔者。
- 關鍵痛點：你必須釐清，這筆預算最終會計入哪一個部門的帳目（Cost Center）？是 IT 部門的基礎建設預算，還是業務部門（如 Sales、Marketing、HR、Finance）的營運成本？
- 項目的定性：只有當預算承擔部門的主管覺得這個系統「有迫切需要」，項目才具備真正的推動力。如果這筆錢計在 A 部門頭上，指令卻由 B 部門發出，這個項目極大機率會在跨部門拉鋸中流產。除非 B 部門擁有絕對的政治凌駕權，能直接強迫 A 部門承擔這筆支出。
🔖意圖定性：劃分專案的執行深度
- 認知盲區：「管理層叫得我研究，就是最高優先級別」。在現實中，有時管理層的確在死線前推行項目以達到KPI，但有時他們是想為將來作一個預算準備，甚至只是應付大老闆的一句奉承說話。
- 執行深度：你必須與主理人釐清項目性質，以決定項目的執行深度。
- 實行導向（Action-oriented）：如果主理人背負著轉型 KPI，希望「盡快實行」，項目的研究重點應放在：方案可行性、技術對接、落地時間與 ROI（投資回報率）。
- 市場調查導向（Exploratory）：如果主理人只是想了解一下或者是應付一下高層指示，策略應改為高層次的市場趨勢報告、價格調查。
💡 N = Need需求
在 BANT 銷售法則中，Need 是為了釐清客戶的痛點，以提供最合適的解決方案；但在機構內部評估中，Need 代表的是「項目真正想達到的核心目的」。許多內部項目最終演變成災難，正是因為團隊錯把管理層提出的手段當成了目的。
🔖目的起源：區分「手段」與「核心需求」
- 認知盲點：「管理層說要換新 ERP，我們就只研究新 ERP」。管理層不是因為興趣而買 ERP，每一個採購指令背後，都源於不同的底層需求。
- 需求多樣性與對應手段：
- 舊系統庫存數據延遲 3 小時，影響出貨效率：可以先了解現有系統為何出錯，有否改善空間。在現有系統上做錯誤修正（Bug Fix）或局部升級（Enhancement）通常比「砍掉重練」更省時便宜。
- 現有的 ERP 未能處理員工薪酬計算：可以考慮額外購買獨立的人力資源系統（HRM）去改善，而不是將整個 ERP 換掉，以免費時失事。
- 機構有硬性 KPI，必須於今年內實施 AI 以滿足董事會要求：要在半年或 9 個月內完全從研究到更換一個 ERP 系統，時間上十分倉促。既然底層需求只是「實施 AI」，可以從其他方向著手（如低風險、能快速落地的 AI 部件或自動化工具）。
- 因為地緣政治因素而需切換 ERP：這個明確的指標，給予了團隊極度清晰的方向，只在某一堆特定地域背景的品牌裡篩選就對了。
🔖 需求定性：劃分「痛點」與「指標偽需求」
釐清目的起源後，員工必須對目的進行定性，這直接決定了研究的側重點：
- 痛點導向型（Pain-point Driven）：不解決公司就會虧錢或降低效率。研究側重點應放在功能匹配度與落地穩定性。員工必須深入基層業務部門，確保新方案能精準止血。
- 指標導向型（KPI Driven）：為了滿足高層指示或年度轉型形象。研究側重點應放在短期的可視成果。此時，迅速做出一個看得見的成果交差，比花半年考究技術底層的完美度更符合高層的真實需求。
💡 T = Timeline時間線
在 BANT 銷售法則中，釐清 Timeline 是為了掌握客戶的採購步伐與期望上線時間；但在機構內部評估中，Timeline 則代表管理層的期望死線與階段性匯報里程碑（Milestones）。
認知盲點：將管理層隨口設定的目標（例如：「我們今年內要換新 ERP」），直接當成真實的執行時間線。如果沒有刺破這種模糊的偽死線，項目極大機率會陷入無限期拖延的泥沼中。
🔖 推敲真實時間線：追溯底層需求的硬死線（Hard Deadline）
要掌握確實的時間線，團隊不能只聽管理層的口頭指令，必須往回追溯在 Need（需求） 中梳理出的底層需求死線。
- 反推邏輯：如果換 ERP 的底層需求是為了因應今年 12 月 31 日生效的地緣政治法規，那麼「12 月底」就是一條不可逾越的硬死線。
- 反向排程（Backward Scheduling）：團隊必須從這條硬死線往前推算，扣除供應商開發（3 個月）、系統測試（2 個月）、員工培訓（1 個月）以及商務談判採購（1 個月）。這意味著，團隊最遲必須在 5 月前完成前期的市場調查。這種理性的反向排程，能立刻讓管理層看清時間的緊迫性，停止不切實際的幻想。
🔖 管理匯報頻率：將「交功課」納入向上管理策略
軟件項目的 Timeline 往往不是在技術對接卡關，而是卡在取得管理層對每一個階段的審批。你必須釐清管理層預期的進度更新頻率（如每週或每月匯報）。
- 政治盲點：許多團隊以為進度匯報只是「到了開會那天，上去報告一下進度」。現實是，沒有令管理層感到滿意的匯報，將直接導致沒法獲得批准進行下一個項目的下一個階段。
- 最佳實踐（Best Practice）：預早計劃匯報內容與簡報。如果等到開會前夕才草率準備，一旦簡報邏輯不理想、無法解答高層的隨興質詢，項目很可能會被勒令暫緩，直至你做到一個令人滿意的報告。這會導致寶貴的執行時間被平白浪費，令 Timeline 嚴重滯後。
結論
在企業管理中，我們不乏麥肯錫 7S（McKinsey 7S）或 IT 組合管理（IT Portfolio Management）等學院派的內部評估框架。然而，這些框架往往假設組織是絕對合理及理性的。現實的職場，反而更像一場充滿跨部門拉鋸、老闆一時興起、以及為了應付董事會的形象工程。這就是為什麼我們需要借用銷售用的 BANT 法則，來冷靜應對這群「內部顧客」。
當管理層再次丟出一個模糊的指令：「你幫手研究下……」的時候，作為員工，最錯誤的應對方式就是立刻打開 Google 盲目搜尋，或者是熬夜做出一份注定成為沉沒成本的精美報告。
在數碼轉型與引入 AI 的浪潮下，企業最缺的從來不是技術，而是看清現實的領航員。在項目正式啟動、投入第一小時的工時之前，不妨先用這套內部 BANT ，看清航道。
Whether it is to save costs or improve operational efficiency, management will inevitably consider digital transformation, introducing AI, or replacing existing management systems. What usually follows is that employees receive a vague directive: “Help me look into this…” What exactly is the real goal, specific requirement, and execution method behind this “looking into”?
A lack of clear direction not only confuses employees but also causes research results to stay forever on paper, unable to be implemented. Whether you are the management giving the directive or the employee responsible for execution, in the very first step of a project launch, we can actually borrow the BANT framework from traditional sales to transform this vague “idea” into a precise “internal needs assessment.”
💡 B = Budget
In traditional sales (Sales BANT), budget refers to how much money is in the client’s pocket; however, in an institutional internal needs assessment (Internal Assessment), budget must be redefined into two dimensions: Tangible Financial Cost and Intangible Resource Cost. Many software projects fail at the very first step precisely because management falls into cognitive blind spots regarding these two dimensions when issuing directives.
🔖 Tangible Cost: Establishing a “Target Range” to Avoid Wasteful Research
When asking employees to “look into a certain solution,” most organizations are often reluctant to disclose the budget ceiling beforehand. This “look-first-and-see-later” blind budget testing is the greatest waste of organizational resources.
- Cognitive Blind Spot: Management believes that “only by setting no limits can we see the best solutions.” But the reality is that the price difference for the same type of software on the market can be as high as 10 times.
- Chain Reaction: Without any guidance, employees might spend weeks researching a top-tier international system with an annual fee of HKD 1 million and write a beautiful evaluation report. It is only at the final approval stage that management reveals the budget is only 300,000. This causes the early employee man-hours and market research to entirely become a worthless Sunk Cost.
- Best Practice: Before starting any research, management must provide a Budget Range. The pricing mechanism of large commercial systems is like a renovation project; it is usually undisclosed or highly customized. The team’s primary task is to obtain a Ballpark Estimate through the original vendor’s sales to quickly filter out solutions that do not fit the budget.
🔖 Intangible Cost: Introducing FTE Assessment to Avoid the Chain Collapse Triggered by “Forced OT”
This is the most common “hidden cost trap” in software projects. Management often only calculates the investment amount to purchase the software, while viewing “employees’ execution time” as free.
- Cognitive Blind Spot: The boss thinks, “I am paying this salary anyway. It doesn’t cost extra money for employees to look into it on the side, coordinate it on the side, or take charge of it on the side.”
- Organizational Cost: According to observations from actual operational data, a medium-to-large software project usually requires an investment of 0.5 to 1 FTE (Full-Time Equivalent) during the initial needs assessment and market research phase, and this needs to last for 1 to 2 months. If dedicated personnel are not allocated, and existing employees are forced to take this on as a side role outside of their daily work through “forced OT,” the organization will face two consequences:
- Perfunctory and Vicious Procurement: Because employees are overwhelmed by their daily work, they can only glance over specifications and rush through the process. Ultimately, the system bought cannot solve the core pain points, resulting in a waste of funds.
- Turnover Risk of Core Employees: The immense pressure of executing the project often becomes the last straw that breaks the employee’s back. When core employees resign due to pressure, the project not only grinds to an immediate halt, but the organization must also bear the heavy cost of talent loss and re-recruitment.
💡 A = Authority
In the BANT sales framework, looking for Authority is about finding the Key Decision Maker who holds the purchasing power. However, in an institutional internal assessment, identifying authority and responsibility is fundamentally about clarifying the project’s political power and resource driving force.
Many teams keep their heads down and work hard on research for months, only for the project to be shelved in the end. The core reason is that they failed to clarify the two core logics behind authority and responsibility in the very first step.
🔖 Financial Ownership: Follow the Money
To judge who the true owner of a software project is, the most direct way is to find out who the paying boss is.
- Cognitive Blind Spot: “The CIO asked me to look into it, so the CIO is the project owner.” But in reality, the coordinator does not equal the budget bearer.
- Key Pain Point: You must clarify which department’s accounts (Cost Center) this budget will ultimately be charged to. Is it the IT department’s infrastructure budget, or the operational costs of a business department (such as Sales, Marketing, HR, or Finance)?
- Project Qualification: The project gains real momentum only when the head of the budget-bearing department feels that this system is an “urgent need.” If this money is billed to Department A, but the directive is issued by Department B, there is a very high probability that this project will fail in cross-departmental tug-of-war. The only exception is if Department B possesses absolute political dominance and can directly force Department A to bear this expense.
🔖 Intent Qualification: Mapping the Execution Depth of the Project
- Cognitive Blind Spot: “Since management told me to look into it, it must be the highest priority.” In reality, while management sometimes pushes a project to meet KPIs before a deadline, they might also just want to prepare a budget for the future, or even simply respond to a flattering remark from the big boss.
- Execution Depth: You must clarify the nature of the project with the owner to determine its execution depth.
- Action-oriented: If the owner carries transformation KPIs and wants to “implement as soon as possible,” the research focus should be on: solution feasibility, technical integration, implementation timeline, and ROI (Return on Investment).
- Exploratory (Market Research Oriented): If the owner just wants to get a general understanding or simply deal with instructions from higher-ups, the strategy should change to high-level market trend reports and pricing surveys.
💡 N = Need
In the BANT sales framework, Need is about clarifying the client’s pain points to provide the most suitable solution; however, in an institutional internal assessment, Need represents the “core objective that the project truly wants to achieve.” Many internal projects ultimately turn into disasters precisely because the team mistakes the solution proposed by management for the actual need.
🔖 Origin of Objective: Distinguishing “Means” from “Core Needs”
- Cognitive Blind Spot: “Management said we need to replace the ERP, so we will only research new ERPs.” Management does not buy an ERP out of personal interest; every procurement directive stems from a different underlying need.
- Diversity of Needs and Corresponding Means:
- Old system inventory data is delayed by 3 hours, affecting shipping efficiency: You can first understand why the current system is failing and see if there is room for improvement. Doing a Bug Fix or an Enhancement on the existing system is usually less time-consuming and cheaper than “scrapping it and starting over.”
- The current ERP cannot handle payroll calculation: You can consider purchasing a separate, standalone Human Resource Management system (HRM) to improve this, rather than replacing the entire ERP, to avoid wasting time and effort.
- The organization has a hard KPI to implement AI within this year to satisfy board requirements: Going from research to completely replacing an ERP system within half a year or 9 months is extremely rushed. Since the underlying need is simply to “implement AI,” you can approach it from other directions (such as low-risk, fast-to-implement AI components or automation tools).
- Need to switch the ERP due to geopolitical factors: This explicit indicator gives the team an extremely clear direction—simply filter and select from a specific pool of brands with the required regional backgrounds.
🔖 Qualification of Need: Dividing “Pain Points” from “KPI Pseudo-Needs”
After clarifying the origin of the objective, employees must qualify the need, which directly dictates the focus of the research:
- Pain-point Driven: If not solved, the company will lose money or experience a drop in efficiency. The research focus should be placed on functional matching and implementation stability. Employees must go deep into frontline business departments to ensure the new solution can precisely stop the bleeding.
- KPI Driven: Done to satisfy high-level directives or the annual image of transformation. The research focus should be placed on short-term, visible results. At this time, quickly delivering a visible outcome to hand in is much more aligned with the real needs of upper management than spending half a year investigating the perfection of the technical core.
💡 T = Timeline
In the BANT sales framework, clarifying the Timeline is about understanding the client’s procurement pace and expected go-live date; however, in an institutional internal assessment, Timeline represents management’s expected deadlines and phased reporting milestones.
- Cognitive Blind Spot: Taking a casual goal set by management (for example: “We need to replace the ERP within this year”) directly as the real execution timeline. If this vague pseudo-deadline is not punctured, the project will have a very high probability of falling into a quagmire of indefinite delays.
🔖 Deducing the True Timeline: Tracing Back to the Hard Deadline of Underlying Needs
To master a reliable timeline, the team cannot just listen to management’s verbal directives; they must trace back to the underlying need deadline uncovered during the “Need” analysis phase.
- Reverse Logic: If the underlying need for changing the ERP is to comply with a geopolitical regulation taking effect on December 31st of this year, then “the end of December” is an insurmountable Hard Deadline.
- Backward Scheduling: The team must calculate backward from this hard deadline, deducting vendor development (3 months), system testing (2 months), employee training (1 month), and commercial negotiation/procurement (1 month). This means the team must complete the initial market research by May at the latest. This rational backward scheduling can immediately make management see the urgency of time and stop impractical illusions.
🔖 Management Reporting Frequency: Integrating “Handing in Homework” into Upward Management Strategies
The Timeline of a software project is often not stuck on technical integration, but rather on obtaining management’s approval for each phase. You must clarify management’s expected frequency for progress updates (such as weekly or monthly reports).
- Political Blind Spot: Many teams think that progress reporting is just “going up to report progress on the day of the meeting.” In reality, a report that fails to satisfy management will directly result in an inability to gain approval to proceed to the next phase of the project.
- Best Practice: Plan reporting content and presentations well in advance. If you wait until the eve of the meeting to rush your preparation, once the logic of the presentation is sub-optimal and fails to answer the casual questions from executives, the project is highly likely to be ordered to suspend until you produce a satisfactory report. This causes precious execution time to be wasted for nothing, severely lagging the Timeline.
Conclusion
In corporate management, we have no shortage of academic internal assessment frameworks, such as the McKinsey 7S model or IT Portfolio Management. However, these frameworks often assume that organizations are absolutely logical and rational. The real workplace, on the contrary, resembles a battleground filled with cross-departmental tug-of-war, the sudden whims of bosses, and image-building projects designed just to appease the board of directors. This is exactly why we need to borrow the sales-based BANT framework to calmly handle this group of “internal customers.”
When management drops another vague directive like “Help me look into this…”, the worst possible response as an employee is to immediately open Google for blind searches, or stay up all night creating a beautiful report destined to become a sunk cost.
Amidst the wave of digital transformation and AI introduction, what enterprises lack most has never been the technology itself, but rather navigators who can see reality clearly. Before a project officially launches and the first hour of labor is invested, it is well worth using this internal BANT framework to map out the channel clearly.