應付賬款涉及資金流動，每筆交易都牽連著供應商的信任和公司的現金流。
過去十年，老ERP系統像個補丁摞補丁的千層蛋糕。
這次渡河專案本是徹底重構的機會，她設計的分散式架構能支撐未來十年的業務擴張，卻卡在了時間節點上。
手機震動，李峰的訊息彈出來：“下午三點，陳總主持方案決策會，必須拿出結論。”
祁燁玲深吸一口氣，把報告折成兩半塞進資料夾。
路過茶水間時，她聽見兩個外包工程師在小聲嘀咕：“聽說馬來西亞子公司的正式上線時間定在5月30號，要是應付模組拖後腿，咱們會不會被問責？”
決策會在鵬城總部G區2305會議室召開，投影上是祁燁玲團隊熬了三個通宵趕出的方案對比表。
左側是 “完美方案”，標註著 “架構先進性★★★★★”“風險等級★★★★”；
右側是 “妥協方案”，“架構先進性★★★”“風險等級★★”。
李峰站在白板前，手中的雷射筆在 “時間視窗” 四個字上反覆畫圈：“渡河專案領導已經很明確，馬來西亞子公司必須在2017年中完成切換，這是政治任務。”
“還有，目前架構下應付模組的資金校驗邏輯和老系統的憑證引擎存在相容性衝突。” 她的聲音帶著獨屬於自己的固執。
她說話之餘指尖敲在鍵盤上，調出一版架構圖，“我們在解耦應付賬款與總賬介面時，忽略了馬來西亞子公司的多幣種結算規則...”
“停。” 李峰抬手打斷，“祁總，我們現在不是在討論技術問題”。
他覺得和麵前這個完美主義者溝通起來真的很痛苦，“現在不是覆盤問題的時候。馬來西亞子公司正式上線日期是2017年5月30日，留給我們的時間只有六個月。”
他轉向坐在長桌盡頭的陳默，“如果按祁總的方案，僅介面聯調就要新增十三週的排期。”
“但妥協方案只是把老架構的補丁換了層皮！” 祁燁玲忍不住插話，“應付模組每天處理12萬筆跨境付款，現有架構的事務處理延遲已經到了450，一旦遇到月末結賬高峰，後果誰來承擔？”
“我們得先按時交付了系統，後續系統出問題的責任才值得討論。” 李峰的聲音裡帶著疲憊，“而且我們完全可以分階段實施！先保障核心流程上線，後續再迭代架構。”
他在努力說服對方，“祁總，你知道嗎？供應鏈模組的兄弟已經在馬來西亞蹲好了，就等咱們應付模組這邊的介面聯調。”
會議室裡的氣氛凝固了。
作為專案經理，更別說李峰自己本身就是公司的金牌架構師。
他比誰都清楚祁燁玲新方案的價值，但他更清楚專案背後的全域性。
這特麼就是典型的理想和現實的差距。
渡河專案是徐董親自掛帥、陳總擔任實際負責人的公司“一號工程”，任何延遲都可能動搖整個自研ERP的信心。
渡河專案分兩大塊，ERP和資料庫。
現在的情況是資料庫那邊進展好的驚人，馮亦如帶著他的博士軍團越幹越high，從開幹至今每一個專案里程碑都是提前完成的。
而自己這邊呢？第一個里程碑是系統解耦，當時堪堪在靠近deadline的時間點完成的。
