Re: 律師帶平版電腦取代卷宗到法院開庭的可行性

[hifree (hifree)]

※ 引述《kcchen (kc)》之銘言：
: 回到前面我說的「非不能也、不為也」議題，卷證資料每一位律師都會印一次，每再換一
: 位律師受任又都再重新印一次（一審律師印一次、二審如更換律師新受任律師一定又會全
: 部卷證再印一次，這是律師最起碼的責任），大家不覺得這實在很浪費嗎？為什麼法院不
: 考慮以販賣卷證資料電子檔給律師的方式取代現行影印的方式？律師買到自己承辦案件電
: 子檔，他要再傳送給當事人，也就只要以電子檔方式傳送即可（現制下很多律師閱完卷後
: 又多拿到外面影印店印給當事人），我相信司法院是「不為也，非不能也。」

  電子化的確是個趨勢,但電子化的問題並不在於檔案掃描,而是掃描之後的檔案管理,那

  才是真正大災難的開始:

  一,電子文件的管理

  假設一個法院一年有3000個案件好了,每個案件約有50個大大小小不等的PDF檔

  所以加總起來一年就有15萬個檔案,這些電子檔案如何管理,就是一個問題,當然你

  可以說我編個目錄好了,每一個案號就是一個目錄,所以這個案號的文件都儲存在

  這麼目錄下,那接下來的問題你要怎麼搜尋?你總不能叫法官一個一個目錄去找吧!

  那他光花在這些搜尋目錄的時間就可以開好幾次庭,寫好幾個判決了,所以一定要

  有一套資料庫系統加以結合,當掃描時就記錄下相關的KEYWORD,以方便將來檔案的

  搜尋而且不允許任何例外情況,以免造成無主檔案的情況


  二,安全性的問題

  有了檔案管理系統之後,接下來的問題就是安全性的問題,誰能閱覽這些檔案?誰能

  修改這些檔案,都必須嚴格的控管,以免造成資料流失或惡意的破壞,如果牽涉到機

  密的文件,更要設定嚴格的保護措施,確保其不會外流與被破解解讀


  三,資料的備源

  有了前二項的之後,第三個棘手的問題是關於資料的備援問題,因為硬碟總有一天會

  壞掉,雞蛋不能放在同一個籠子裡,你必須有相關的資料備源系統確保文件的完整性,

  不會因為某顆硬碟的毀損而消失無蹤,這就是一筆大投資與大工程了,足以養活一個

  企業.


  四,不同法院層級的電子文件交換

  此時要回復到一個問題,如何把下級法院的電子檔完全無誤地傳送到上級法院,或者

  在同層級的不同法院間的資料交換,而且確保其資料的一致性,不會因為某個法院改

  了那筆資料而其他法院沒有即時更正到,造成彼此間資料認定的不一致性,而影響裁

  判結果



  以上都還只是最簡單的思考而已,實作上還有許多困難必須克服,而電子化絕對不是

  問題,問題是電子化後的文件管理,那才是一個真正的大問題,而且還是個無底洞


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.194.111.225
推 ixixet:原PO有遇過這類問題嗎？總覺得好簡單卻詳細啊...
  資工所的課旁聽一年就懂了

  問題不在理論,而在實做,實作上什麼奇奇怪怪的問題都會發生

  那才是最麻煩的地方

※ 編輯: hifree          來自: 123.194.111.225      (01/15 02:35)
→ yike:基本上寫個搜索程式就可以爬整個資料庫，含檔案內。
問題沒那麼簡單

此包括資料的上傳與資料庫系統的正規化問題

特別是嚴格要求所有的檔案必須經過系統程式才能上傳管理

以免未登錄的檔案流竄在系統中,無法管理

舉個例子,我之前待過的公司就碰過這個問題

系統使用二個流水號作為案件的管理依據

但律師們仍習慣用客戶名稱來命名

完全沒按照系統的要求儲存檔案

反而是在自己個人儲存空間另建檔案目錄資料夾

造成檔案資料與系統資料庫無法串連的問題

也影響前後手的交接問題

你可以想想看

如果書記官或司法事務官不管系統自己亂建檔案目錄名稱會有什麼嚴重的後果

這是司法院在採行全面電子化時不得不優先考量的觀點

如何要求所有人員必須依照系統要求建置電子檔

那才是電子化成功與否的關鍵

→ yike:資料備份稍大點的網路公司都有做，技術成熟，不是大問題。
ㄟ

我說的不是硬碟或磁帶備份這種LOW TECH的東西

我說的是磁碟陣列這種資料交錯儲存模式(Bit－interleaving)

如何避免某一個Bit的資料毀損不影響整體資料的解讀

並且能與資料庫系統完全配合

有些東西不是光ghost就可解決的

特別是資料庫系統檔案的儲存

那才是關鍵

市面上有支援此種技術的關鍵廠商屈指可數

而其建置費用都是千萬起跳

→ sese5566:常年的額外預算編列才是大問題 另外還有同步與編碼的問題
→ sese5566:待過不同院就能明白目前要院際電子整合是多麼困難的事
→ sese5566:以法院的文書量而言資料庫工程真的不是這麼簡單的
→ sese5566:法院連文書軟體都要自己搞司法文書系統了沒花錢買套裝
→ sese5566:軟體(或者院內少數電腦才有)了 技術面都不提 要額外獲得
→ sese5566:建置電子化整合與資料庫同步等的首期預算可能性都存疑了
→ sese5566:更不要說常年編製預算維護維持 再者以目前各院總務科的
→ sese5566:資訊程度有能力發包與驗收都存疑了 各院資訊室編制也不足
→ sese5566:人數支援如此業務 最後還是得委外 又衍生內控資安問題
→ sese5566:只能說很多事不是一句輕描淡寫這麼簡單的 即使技術面也是
→ sese5566:更別說在民間企業聽來不是問題的在院內環境(含人事)
→ sese5566:下亦非問題
→ sese5566:審判業務行政可以找幾個大頭法官與行政長官開開會解決
→ sese5566:院內而言大頭法官與行政長官都不了的資訊事宜就很難期待
推 marcox:支持S大的見解   司法雲端化執行面需要許多考量
→ sese5566:只能說是個非常值得努力的方向 但絕非易事
→ sese5566:上有錯字更正..民企不是問題的在院內'非亦不是問題'才對
推 volkov:只有一個問題，就是要不要去找預算
→ volkov:您說的問題，很多您自己都有解答了，最大問題還是在於預算
→ sese5566:並非有解就不是問題 這就是公部門。亦非只有'一個'問題
推 volkov:有解的意義，一向不代表能完全預防問題
→ kaky:亂建檔名並不是什麼難事上傳時系統重新命名非以自建檔名存檔
→ kaky:當然檔案安全還有系統的存取安全性是很大的問題
推 potatola:有聽說司法院有開始進行卷證電子化的推動了，先前還把
→ potatola:一位資工博班背景的法官調院辦事，大概要負責寫程式吧 :p
※ 編輯: hifree          來自: 59.120.39.93         (01/15 16:13)
推 chihchien:台中地院試行
推 jdkcupid:你把問題想得太複雜了 問題是出在法院資訊採購
→ jdkcupid:而不是技術面的問題 法院資料庫的量跟USPTO比如何
→ jdkcupid:跟智慧局比又如何 這些處理技術上都不是問題
→ jdkcupid:沒有人講資料備援會去講到Ghost 至少就是從Raid規劃開始
→ jdkcupid:USPTO做法 就是XML下去 IBM的資料庫
→ jdkcupid:法院現在內部判決本來就電子化了 只是要把電子化步驟
→ jdkcupid:提前到分案開始 以及書面證據的電子化
→ jdkcupid:你講的那些問題，基本上在法院都很容易解決，因為法院
→ jdkcupid:建檔系統本來就是封閉的
→ jdkcupid:智慧局這種要給不特定人使用的系統才麻煩
→ jdkcupid:而且目錄跟資料夾早就是舊觀念了
→ jdkcupid:現在都是XML 裏面包含tag 跟metadata
→ jdkcupid:會去講資料夾 跟目錄 又不是在架FTP
→ jdkcupid:而資訊維護的部份 重點只是法院要不要弄個部門來用而已
我當然知道技術面不是問題

而我前面也說過了理論上一點困難都沒有

問題在於實作

你如何應付那些奇奇怪怪的問題才是整個系統的麻煩之處

而這些在技術上通通是可以解決的

問題在於業主有沒有耐心忍耐你系統的不穩定性

舉個例子

我十年前還在ACER軟體開發程式時

一家銀行要求我們在一個月內完成他們的HR系統

而我們也達到了

但是有一個小問題

就是上傳照片的時候不穩定

有時候成功有時候失敗

結果我們花了三天三夜好不容易找出原因

原來是一個VBA物件註冊權限的問題

結果業主後來說不要了

因為他們覺得我們的系統不穩定

這只是一個小問題而已

但對於業主來說卻是一個大麻煩

他寧可放棄這筆CASE也不要因為這的小小的不穩定去影響他的商機

你說這是不是個問題?

技術有沒有難度?

為什麼業主不肯接受?

這就是理論與實務的差距啊

在學校裡寫作業開發專案教授可以容忍你的小瑕疵

但在企業裡完全不能容忍這種錯誤

因為你的一個小錯誤就是幾千億的損失

你承擔得起嗎?

更別提司法系統這麼複雜的機制

會容許你軟體開發廠商try and error的方式達到目標嗎?

當然是要求一次到位

所以投標廠商的規模與業績就是一個篩選機制

所付出的代價就是龐大的預算與後緒維修合約

→ hifree:樓上我可以確定法院每年的收件量遠高於智慧咼
→ hifree:以民國九十六年為例,民事新收三十萬件
推 jdkcupid:這個我就不清楚了 不過USPTO基本上就做的很好了
→ hifree:刑事三十七萬件,這還只是地院,不含高等,最高還有行政法院
推 jdkcupid:基本上 檔案量不會影響系統設計難度 那只是一開始要先
→ jdkcupid:想好 重點還是你院內舊有格式轉換 還有招標的問題
→ jdkcupid:問題應該是出在 依照台灣招標現況 一定是悲劇
→ jdkcupid:而且法院的檔案算小的 沒有圖~
→ jdkcupid:專利有圖 即便件數少 檔案大小隨便都是判決的好幾倍
→ hifree:另外目錄只是舉例,我當然知道系統建置後就不可能再手動
→ hifree:儲存了,重點還是在於各類不同文件的交換處理
→ hifree:而且要在不影響現有作業模式進行
→ hifree:會有相當大的陣痛
→ hifree:法院多的是圖好不
→ hifree:一些鑑定勘驗都是圖檔,還有影音檔
※ 編輯: hifree          來自: 123.194.111.225      (01/15 22:17)
→ sese5566:推回文 技術面有解≠技術面不是問題
推 volkov:因為沒有solution是完美的
→ volkov:預算，也就是政治面才是最大問題，好技術也可能會歪七扭八
→ volkov:能否爭取足夠的預算，一直是最難的
→ sese5566:回文業主不接受的例子就不是預算的問題了
→ sese5566:應該說不只是預算 而業主這種心態出現院方大頭身上無違和
推 Rhomboid:在怎麼多都不會比電子病歷多啦～ 有心都可以做到
推 Rhomboid:問題在於招標招不出好的solution吧
推 sese5566:電子病例跟訴訟文書性質差遠了