前言

在第 1 回與第 2 回裡，我們確認 EUC 與神 Excel 雖然短期拯救第一線，卻為組織留下了長期的負資產。 本篇把視角拉回現在，檢視 RPA 與無代碼／低代碼等現代公民開發平台的明與暗。

它們既是神 Excel 的重演，也因規模與依賴度而潛藏更大的風險。為了在下一回討論生成式 AI 的衝擊，必須先正確理解這些特性。

全系列

光：為何迅速被接受

立即見效的速度

不必寫程式，只靠 GUI 操作就能迅速完成簡單的自動化或應用。在短短幾天內就能取代每日抄寫或例行流程，對第一線而言價值巨大。

「可視化」的說服力

把流程與畫面做成任何人都看得懂的圖表，連沒有專業知識的族群也能理解。對經營層來說，看到「會動的畫面」就像看到成果本身，往往成為推動導入的決定性因素。

公民踏出的第一步

在輸入表單或簡易流程等限定用途下，非工程背景的人確實可以自行打造工具。至少在這個層級，確實能感受到「誰都能做」，成為組織擴大公民開發參與面的入口。

影（1）：實務中浮現的「專業之牆」

表面上看似「誰都能用」，但只要想在實務上正規運用，最終仍離不開等同程式設計的思維與系統工程視角。

  • 控制結構無法逃避 依客戶條件分支處理就必須有條件判斷（If/Else）。要處理數百筆資料則必須使用迴圈（ForEach）。為了預防外部系統的延遲或錯誤，異常處理（Try/Catch）是必須存在的。GUI 只是換了一種堆疊方式，本質依然是程式設計。

  • 必須理解資料結構 展開 JSON 或陣列、映射階層、統一日期與數值格式——這些都是業務整合不可或缺的工作。僅靠表格式思維無法收拾，缺乏資料結構知識就會崩潰。

  • 系統間整合仍然複雜 API 認證的有效期管理、跨系統一致性的維持、速率限制的規避等，與傳統軟體工程的課題如出一轍。只是被 GUI 隱藏起來，難度甚至更高。

  • 營運與品質需求依舊存在 監控、日誌收集、測試與正式環境的差異管理、發佈時的回復計畫——少了這些營運設計，很快就會陷入混亂。無法以程式管理的部分，可觀測性也往往下降。

面對這堵牆，公民開發者難以獨自構建並維持可在生產使用的系統，最終仍得依賴專業技術人員。原本的產能瓶頸並沒有因此解決。

影（2）：廠商鎖定與遷移的困境

神 Excel 至少還有救贖：它是一個檔案。表格資料可以匯出為 CSV，函數與巨集雖然依賴 Excel，但仍有其他試算軟體能部分相容，程式碼也能閱讀。 反觀 RPA 與無代碼／低代碼的成果，大多被封在平台專屬的 UI 或設定檔裡。

  • 換用其他產品幾乎等同於「重新從零打造」。
  • SaaS 終止服務或修改規格不由使用者掌控，累積的資產可能一夜清零。
  • 架在 PaaS 上時會被該雲端生態綁死，要搬到其他環境極度困難。
  • 以 UI 而非程式碼定義邏輯，導致問題位置難以搜尋、難以發現。
  • 視工具設計而定，有些甚至得雙擊元件才能看到內部處理，閱讀性大幅下降。

與仍能以檔案為單位收尾的神 Excel 相比，依賴度與債務風險都高出許多。

影（3）：讓經營層著迷的「可視化偏差」

技術人員一眼就知道終究會撞上「專業之牆」。 然而經營層看到用 GUI 繪製的流程或畫面，就很容易認為「這誰都能用」。

為什麼？因為在經營層眼中，系統平時就是黑箱。當看到箭頭串連的業務流程與輸入表單，就會誤以為自己已經理解了內部的複雜度。 但現實是，背後依然是同樣的控制邏輯與錯誤處理，要撐過實務運用仍離不開工程知識。

這種「經營層的安心感」與「技術者的警惕」之間的落差，一方面加速導入，另一方面也成了擴大未來債務的溫床。

走向「神 Excel 2.0」的時代

綜合來看，RPA 與無代碼／低代碼正重演神 Excel 的劇本。 它們以立即見效救了一線、以可視化說服經營層，最終伴隨黑箱化與個人化，為組織留下沉重包袱。

決定性的差異在於影響範圍。神 Excel 仍停留在檔案層級，現代公民開發卻嵌入雲端與整個核心業務，可能演變成綁住整個組織的債務。 再加上比 Excel 更強的鎖定結構，足以引來所謂的「神 Excel 2.0」。

總結

  • RPA 與無代碼／低代碼以立即見效與可視化的說服力，獲得第一線與經營層的青睞。
  • 然而要支撐實務，仍需掌握控制結構、資料結構、系統整合、營運設計等軟體工程知識，單靠公民開發者無法獨立負擔。
  • 平台專屬的 UI 讓遷移變得極為艱難，也進一步強化廠商鎖定。
  • 經營層的「可視化偏差」讓這些風險被低估。

現代公民開發的威力超越神 Excel，同時也更加危險。 下一回，我們將檢視當生成式 AI 加入這股潮流時會發生什麼。

下一回：生成式 AI 會拯救哪些遺產，又會放棄哪些？4/7