2026年8月7日 星期五

30種企業知識庫應用 30 公部門與公營事業

第一個月承辦說缺文件,第三個月輪調後說前一份不用、要補另一份,第四個月代理的人說案子性質改變要換法條重審——三個人都依法辦理、都拿得出依據,歷時四個月,民眾投書。 這一集示範怎麼把「這則函釋影響了我們哪些既有做法」問成一次多跳查詢,一路帶出曾被糾正的前例;以及四條在公部門不能退讓的鐵則,包括它只能是內部知識管理,不作為行政處分依據。


這裡是智庫引擎,專為企業設計的知識庫。本集是這個系列的最後一集,我們走進公部門與公營事業。

畫面上這個問句,大概是每個機關都遇過的事:承辦換人,案子為何總要從頭再來?

底下那段引言,把整件事講得很完整——輪調是制度,斷層是代價。而這個代價,一直是民眾在付。

請注意,這一集不會主張取消輪調。輪調有它的道理,也不會改。我們要處理的是後面那半句:怎麼讓斷層的代價,不要落在民眾身上。

我們從民眾的角度看一件案子。

第一個月,承辦 A 說缺文件,民眾就去補件。

第三個月,承辦輪調了,承辦 B 說:前一份不需要,要補另外一份。民眾再補一次。

第四個月,承辦 B 也不在,代理的承辦 C 說:這個案子性質改變了,要換法條重新審查。

歷時四個月,民眾投書。

畫面右下角那一格請一定要看清楚:三個人都沒錯。每一位都依法辦理,每一位都拿得出依據。

錯在「以前這種案子是怎麼辦的」從來沒有被寫下來,只存在於歷任承辦的記憶中。

所以這不是態度問題,也不是誰不用心。是那個資訊根本沒有一個地方在放。

而且請注意,這件事對機關來說也是損失。四個月的往返,機關這邊也重複審查了三次,還多收了一封投書。民眾累,承辦也累,只有那份「以前怎麼辦的」一直沒有出現。

那交接的時候不是有清單嗎?

這一頁把清單拆成兩半。

左邊是留得下來的,都是狀態:案件清單、待辦事項、實體公文、檔案位置。這一半其實做得很好。公部門的檔案管理,通常比多數民間企業嚴謹。

右邊是帶不走的,都是判斷:一貫見解、上級口頭指示、跨機關協調默契,還有法規與函釋的網狀關係。

四項裡面沒有一項寫在紙上。

中間那位科長的話講得非常精準:我們的檔案管理很完整,每一份公文都在。但公文告訴你「辦了什麼」,不會告訴你「為什麼這樣辦」。

畫面最底下這句話,就是這一集的診斷:公部門的知識問題,不是沒有紀錄,是紀錄裡沒有判斷。

這個診斷很關鍵,因為它決定了處方。如果診斷是「紀錄不足」,那就再加幾份表;但真正缺的那四項,加表格是加不出來的。

判斷散在哪裡?

畫面上這張圖畫得很清楚。中間那個檔案系統,接得住的只有兩種東西:公文跟簽呈。

上面漂著三塊接不住的:函釋、會議紀錄與電話,還有承辦人的大腦。第三塊最麻煩,因為它會走。

畫面中間那一行是這一頁的重點:法規與函釋是網狀的。一則新的函釋,可能同時修正三項既有的見解——而它們之間的關係,沒有人在維護。

所以底下那句結論才成立:問題不在交接不確實,在於歷任判斷的「關係」無法被查詢。

請記住「關係」這兩個字,這一集後半都在講怎麼把它找回來。

順帶一提,這也是為什麼「把公文全部數位化」解決不了這件事——公文數位化之後,還是一份一份的公文,關係依然沒有人維護。

那要怎麼把關係找回來?

先從產線講起。

畫面左邊是原料區,四種:法規條文、上級函釋、簽辦要旨,還有會議錄音。

請注意第三項跟第四項。簽辦要旨裡藏著承辦當時的判斷,會議錄音裡藏著協調的默契——這兩種東西平常不會有人回頭去看。

中間是蒸餾區:去掉贅字,把民眾姓名、身分證字號這些個資蓋掉,然後分類、摘要。

右邊是產出區:可以互相連結的概念頁,還有歷任的判斷。

畫面最底下那句話請記住:這不是雲端硬碟,也不是把檔案丟給人工智慧就算數,它是一條把原料煉成可查詢知識的產線。

關係是怎麼被抽出來的?

這一頁是全集技術含量最高、但也最好懂的一頁。

畫面左邊是一段很典型的公文文字:依某年函釋規定,將限縮原第某條之適用範圍。若遇特定情形,須先函詢上級機關。

這段話人看得懂,但沒辦法查。

畫面右邊是抽出來的結果,變成兩組關係。

第一組:某年函釋,限縮,第某條之適用。

第二組:特定情形,須先函詢,上級機關。

請注意中間那兩個括號裡的詞——限縮、須先函詢。那就是「關係」。

畫面最底下那句話說明了它的價值:系統從核可過的知識頁裡抽出實體與關係,自己建立一套機關專屬的微型邏輯網。

機關專屬這四個字很重要:這張網不是通用的,它長的是您們機關的樣子。

別的機關對同一條法規可能有不同的一貫見解,那不是誰對誰錯,那是各自累積出來的實務。所以這張網不能外面買現成的。

有了那張網,能做什麼?

畫面上左右對照。

左邊是一般搜尋,它只能回答一件事:跟這句話最像的內容是哪幾段?

這種搜尋撈回來的是一堆文件,還是要人自己讀、自己判斷。

右邊叫圖譜多跳查詢。它回答的是:這則函釋影響了我們哪些既有做法?

底下那條路徑就是它走的路:函釋限縮了條文,條文改變了案件類型,這類案件須要函詢,函詢時機關聯到曾經被糾正的前例。

四次跳躍,走到了一個沒有人問過、但非常關鍵的地方——曾被糾正的前例。

這正是第四頁講的「網狀關係」。

一般搜尋走不到第二跳,因為它只比對相似度,不認得關係。

換個角度看:左邊那種搜尋的使用者,還是得靠自己的經驗把線串起來——而新來的承辦,缺的正是那個經驗。

實際用起來是什麼樣子?

畫面上是一位新人上任第一個月的提問。

他問:這類案件要適用哪一條?要不要函詢?

回答分成兩塊。

第一塊:原則依第某條辦理;但若同時涉及特定情形,依某年函釋應改依另一條處理,而且須先函詢上級。

第二塊是關鍵:過去曾有未經函詢逕行核准而遭糾正之案例。

這一句,新人不可能自己想到要問。是那張關係網把它帶出來的。

底下附了出處:某年函釋,加上業務研討會議錄音的逐字稿第二十二分鐘。

畫面最底下那句話值得念完:新人熟悉業務的時間縮短三成到五成。同樣一件案子,一個從頭再來,一個接著往下。

這一頁是誠實話,四個鐵則,缺一不可。

第一,關係是系統提出來的,要人核可才生效。畫面上寫得很直接:機器說的不能直接當依據,這道人工是必要的。

第二,知識頁要先被審核,才能抽出關係。所以導入的時候必須指定審核人,而且要排進常態的工作分配裡,不能靠加班或靠自願。

第三,系統不會自動偵測法規異動。標記「已過時」這件事,還是要靠機關的標準流程去更新。

第四,也是最重要的一條:這是純內部的知識管理,不是行政處分的依據。個案的法律適用,仍然應該依法令與權責程序辦理。

第四條請務必念清楚——它是這套系統在公部門能不能用的前提。

把這四條合起來看,它們其實在講同一件事:系統負責把該看的資料擺到承辦面前,但決定怎麼辦的,永遠是人。

這四條也是導入計畫書裡一定要寫進去的四句話,因為審查的人一定會問。

最後這一頁的問題,請帶回科裡問一次:您們科裡的處理慣例,寫在哪裡?

底下那句話很有畫面:十年下來,輪調清空了記憶三到四次。

三到四次,等於同一套判斷被重新摸索了三到四次,而每一次的成本,都是民眾在付。

右邊是三個可以先盤點的問題。

第一,函釋與簽辦要旨目前怎麼存?

第二,哪一類案件最常見解不一?

第三,從哪個業務項目開始試點?

建議從第二題那類案件開始——最常見解不一的,就是最需要一貫見解的。

畫面最底下那行小字要念清楚:本集情境為示範案例,數字是導入目標與合理預期;這套系統是內部知識管理工具,不作為行政處分的依據,也不提供法律意見。

三十種行業,我們一路走到這裡。

這裡是智庫引擎,感謝您的收看。

30種企業知識庫應用-01-精密機械與工具機製造

30種企業知識庫應用-02-電子製造代工

30種企業知識庫應用-03-化工與塗料材料

30種企業知識庫應用-04-食品加工

30種企業知識庫應用-05-紡織與成衣染整

30種企業知識庫應用-06-模具製造

30種企業知識庫應用-07-半導體與自動化設備商

30種企業知識庫應用-08-金屬加工與表面處理

30種企業知識庫應用-09-營建與土木工程

30種企業知識庫應用-10-機電空調工程

30種企業知識庫應用-11-建築師與室內設計事務所

30種企業知識庫應用-12-醫院與診所體系

30種企業知識庫應用-13-長照與照護機構

30種企業知識庫應用 14 製藥與醫療器材

30種企業知識庫應用 15 會計師事務所

30種企業知識庫應用 16 律師事務所

30種企業知識庫應用 17 管理顧問公司

30種企業知識庫應用 18 人力資源顧問與人力派遣

30種企業知識庫應用 19 廣告與行銷代理商

30種企業知識庫應用 20 系統整合商

30種企業知識庫應用 21 軟體與SaaS公司

30種企業知識庫應用 22 資訊委外與MSP

30種企業知識庫應用 23 銀行與金融機構

30種企業知識庫應用 24 保險經紀與代理

30種企業知識庫應用 25 證券與投顧

30種企業知識庫應用 26 連鎖餐飲

30種企業知識庫應用 27 零售與電商

30種企業知識庫應用 28 物流與倉儲

30種企業知識庫應用 29 旅宿與飯店集團

30種企業知識庫應用 30 公部門與公營事業

沒有留言:

張貼留言