Re: 律師帶平版電腦取代卷宗到法院開庭的可行性
※ 引述《kcchen (kc)》之銘言:
: 回到前面我說的「非不能也、不為也」議題,卷證資料每一位律師都會印一次,每再換一
: 位律師受任又都再重新印一次(一審律師印一次、二審如更換律師新受任律師一定又會全
: 部卷證再印一次,這是律師最起碼的責任),大家不覺得這實在很浪費嗎?為什麼法院不
: 考慮以販賣卷證資料電子檔給律師的方式取代現行影印的方式?律師買到自己承辦案件電
: 子檔,他要再傳送給當事人,也就只要以電子檔方式傳送即可(現制下很多律師閱完卷後
: 又多拿到外面影印店印給當事人),我相信司法院是「不為也,非不能也。」
電子化的確是個趨勢,但電子化的問題並不在於檔案掃描,而是掃描之後的檔案管理,那
才是真正大災難的開始:
一,電子文件的管理
假設一個法院一年有3000個案件好了,每個案件約有50個大大小小不等的PDF檔
所以加總起來一年就有15萬個檔案,這些電子檔案如何管理,就是一個問題,當然你
可以說我編個目錄好了,每一個案號就是一個目錄,所以這個案號的文件都儲存在
這麼目錄下,那接下來的問題你要怎麼搜尋?你總不能叫法官一個一個目錄去找吧!
那他光花在這些搜尋目錄的時間就可以開好幾次庭,寫好幾個判決了,所以一定要
有一套資料庫系統加以結合,當掃描時就記錄下相關的KEYWORD,以方便將來檔案的
搜尋而且不允許任何例外情況,以免造成無主檔案的情況
二,安全性的問題
有了檔案管理系統之後,接下來的問題就是安全性的問題,誰能閱覽這些檔案?誰能
修改這些檔案,都必須嚴格的控管,以免造成資料流失或惡意的破壞,如果牽涉到機
密的文件,更要設定嚴格的保護措施,確保其不會外流與被破解解讀
三,資料的備源
有了前二項的之後,第三個棘手的問題是關於資料的備援問題,因為硬碟總有一天會
壞掉,雞蛋不能放在同一個籠子裡,你必須有相關的資料備源系統確保文件的完整性,
不會因為某顆硬碟的毀損而消失無蹤,這就是一筆大投資與大工程了,足以養活一個
企業.
四,不同法院層級的電子文件交換
此時要回復到一個問題,如何把下級法院的電子檔完全無誤地傳送到上級法院,或者
在同層級的不同法院間的資料交換,而且確保其資料的一致性,不會因為某個法院改
了那筆資料而其他法院沒有即時更正到,造成彼此間資料認定的不一致性,而影響裁
判結果
以上都還只是最簡單的思考而已,實作上還有許多困難必須克服,而電子化絕對不是
問題,問題是電子化後的文件管理,那才是一個真正的大問題,而且還是個無底洞
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.194.111.225
推
01/15 02:15, , 1F
01/15 02:15, 1F
資工所的課旁聽一年就懂了
問題不在理論,而在實做,實作上什麼奇奇怪怪的問題都會發生
那才是最麻煩的地方
※ 編輯: hifree 來自: 123.194.111.225 (01/15 02:35)
→
01/15 03:09, , 2F
01/15 03:09, 2F
問題沒那麼簡單
此包括資料的上傳與資料庫系統的正規化問題
特別是嚴格要求所有的檔案必須經過系統程式才能上傳管理
以免未登錄的檔案流竄在系統中,無法管理
舉個例子,我之前待過的公司就碰過這個問題
系統使用二個流水號作為案件的管理依據
但律師們仍習慣用客戶名稱來命名
完全沒按照系統的要求儲存檔案
反而是在自己個人儲存空間另建檔案目錄資料夾
造成檔案資料與系統資料庫無法串連的問題
也影響前後手的交接問題
你可以想想看
如果書記官或司法事務官不管系統自己亂建檔案目錄名稱會有什麼嚴重的後果
這是司法院在採行全面電子化時不得不優先考量的觀點
如何要求所有人員必須依照系統要求建置電子檔
那才是電子化成功與否的關鍵
→
01/15 03:12, , 3F
01/15 03:12, 3F
ㄟ
我說的不是硬碟或磁帶備份這種LOW TECH的東西
我說的是磁碟陣列這種資料交錯儲存模式(Bit-interleaving)
如何避免某一個Bit的資料毀損不影響整體資料的解讀
並且能與資料庫系統完全配合
有些東西不是光ghost就可解決的
特別是資料庫系統檔案的儲存
那才是關鍵
市面上有支援此種技術的關鍵廠商屈指可數
而其建置費用都是千萬起跳
→
01/15 05:43, , 4F
01/15 05:43, 4F
→
01/15 05:45, , 5F
01/15 05:45, 5F
→
01/15 05:46, , 6F
01/15 05:46, 6F
→
01/15 05:48, , 7F
01/15 05:48, 7F
→
01/15 05:49, , 8F
01/15 05:49, 8F
→
01/15 05:50, , 9F
01/15 05:50, 9F
→
01/15 05:52, , 10F
01/15 05:52, 10F
→
01/15 05:53, , 11F
01/15 05:53, 11F
→
01/15 05:54, , 12F
01/15 05:54, 12F
→
01/15 05:56, , 13F
01/15 05:56, 13F
→
01/15 05:57, , 14F
01/15 05:57, 14F
→
01/15 05:57, , 15F
01/15 05:57, 15F
→
01/15 06:00, , 16F
01/15 06:00, 16F
→
01/15 06:00, , 17F
01/15 06:00, 17F
推
01/15 06:44, , 18F
01/15 06:44, 18F
→
01/15 07:00, , 19F
01/15 07:00, 19F
→
01/15 07:36, , 20F
01/15 07:36, 20F
推
01/15 08:47, , 21F
01/15 08:47, 21F
→
01/15 08:47, , 22F
01/15 08:47, 22F
→
01/15 09:41, , 23F
01/15 09:41, 23F
推
01/15 10:58, , 24F
01/15 10:58, 24F
→
01/15 15:23, , 25F
01/15 15:23, 25F
→
01/15 15:24, , 26F
01/15 15:24, 26F
推
01/15 16:03, , 27F
01/15 16:03, 27F
→
01/15 16:04, , 28F
01/15 16:04, 28F
※ 編輯: hifree 來自: 59.120.39.93 (01/15 16:13)
推
01/15 16:38, , 29F
01/15 16:38, 29F
推
01/15 18:26, , 30F
01/15 18:26, 30F
→
01/15 18:27, , 31F
01/15 18:27, 31F
→
01/15 18:27, , 32F
01/15 18:27, 32F
→
01/15 18:28, , 33F
01/15 18:28, 33F
→
01/15 18:30, , 34F
01/15 18:30, 34F
→
01/15 18:31, , 35F
01/15 18:31, 35F
→
01/15 18:33, , 36F
01/15 18:33, 36F
→
01/15 18:35, , 37F
01/15 18:35, 37F
→
01/15 18:35, , 38F
01/15 18:35, 38F
→
01/15 18:36, , 39F
01/15 18:36, 39F
→
01/15 18:37, , 40F
01/15 18:37, 40F
→
01/15 18:38, , 41F
01/15 18:38, 41F
→
01/15 18:38, , 42F
01/15 18:38, 42F
→
01/15 18:39, , 43F
01/15 18:39, 43F
我當然知道技術面不是問題
而我前面也說過了理論上一點困難都沒有
問題在於實作
你如何應付那些奇奇怪怪的問題才是整個系統的麻煩之處
而這些在技術上通通是可以解決的
問題在於業主有沒有耐心忍耐你系統的不穩定性
舉個例子
我十年前還在ACER軟體開發程式時
一家銀行要求我們在一個月內完成他們的HR系統
而我們也達到了
但是有一個小問題
就是上傳照片的時候不穩定
有時候成功有時候失敗
結果我們花了三天三夜好不容易找出原因
原來是一個VBA物件註冊權限的問題
結果業主後來說不要了
因為他們覺得我們的系統不穩定
這只是一個小問題而已
但對於業主來說卻是一個大麻煩
他寧可放棄這筆CASE也不要因為這的小小的不穩定去影響他的商機
你說這是不是個問題?
技術有沒有難度?
為什麼業主不肯接受?
這就是理論與實務的差距啊
在學校裡寫作業開發專案教授可以容忍你的小瑕疵
但在企業裡完全不能容忍這種錯誤
因為你的一個小錯誤就是幾千億的損失
你承擔得起嗎?
更別提司法系統這麼複雜的機制
會容許你軟體開發廠商try and error的方式達到目標嗎?
當然是要求一次到位
所以投標廠商的規模與業績就是一個篩選機制
所付出的代價就是龐大的預算與後緒維修合約
→
01/15 18:42, , 44F
01/15 18:42, 44F
→
01/15 18:44, , 45F
01/15 18:44, 45F
推
01/15 18:44, , 46F
01/15 18:44, 46F
→
01/15 18:47, , 47F
01/15 18:47, 47F
推
01/15 18:48, , 48F
01/15 18:48, 48F
→
01/15 18:48, , 49F
01/15 18:48, 49F
→
01/15 18:49, , 50F
01/15 18:49, 50F
→
01/15 18:50, , 51F
01/15 18:50, 51F
→
01/15 18:51, , 52F
01/15 18:51, 52F
→
01/15 18:54, , 53F
01/15 18:54, 53F
→
01/15 18:57, , 54F
01/15 18:57, 54F
→
01/15 18:58, , 55F
01/15 18:58, 55F
→
01/15 18:59, , 56F
01/15 18:59, 56F
→
01/15 19:01, , 57F
01/15 19:01, 57F
→
01/15 19:05, , 58F
01/15 19:05, 58F
※ 編輯: hifree 來自: 123.194.111.225 (01/15 22:17)
→
01/15 23:55, , 59F
01/15 23:55, 59F
推
01/16 10:32, , 60F
01/16 10:32, 60F
→
01/16 10:33, , 61F
01/16 10:33, 61F
→
01/16 10:34, , 62F
01/16 10:34, 62F
→
01/16 11:02, , 63F
01/16 11:02, 63F
→
01/16 11:03, , 64F
01/16 11:03, 64F
推
01/24 20:18, , 65F
01/24 20:18, 65F
推
01/24 20:21, , 66F
01/24 20:21, 66F
推
01/25 07:13, , 67F
01/25 07:13, 67F
討論串 (同標題文章)
Lawyer 近期熱門文章
PTT職涯區 即時熱門文章