辦公自動化系統就是使用計算機系統執行一系列辦公操作。下面YJBYS小編為大家搜尋整理了關於辦公自動化系統的設計與實現，歡迎參考閱讀，希望對大家有所幫助!想了解更多相關資訊請持續關注我們應屆畢業生培訓網!
利用網路通訊基礎及先進的網路應用平臺，建設一個安全、可靠、開放、高效的資訊網路和辦公自動化、資訊管理電子化系統，為管理部門提供現代化的日常辦公條件及豐富的綜合資訊服務，實現檔案管理自動化和辦公事務處理自動化，以提高辦公效率和管理水平，實現企業各部門日常業務工作的規範化、電子化、標準化，增強檔案部門文書檔案、人事檔案、科技檔案、 財務檔案等檔案的可管理性，實現資訊的線上查詢、借閱，最終實現“無紙”辦公。
1需求分析
1.1功能需求
本系統是為某校辦公自動化的需要而開發的，該學校需要解決如下問題：創造一個整合化的辦公環境;支援資訊傳遞;提供具有工作流性質的處理過程和監督功能;提供整合處理與釋出資訊的工作平臺;實現文件管理的自動化;提供與其它管理資訊系統( MIS )的資訊交流。
1.2功能介紹
辦公自動化系統功能介紹
1.3 流程圖
公文流轉系統分為三個功能模組。
(1)發文管理模組：發文管理即各個部門提交報文，檔案不指定路線，由發文的個人制定流程，報文以附件方式傳送，每個使用者只需要選擇“轉呈”下拉選單中的下一轉呈人，該公文就會自動流轉到下一個處理人手中，由每個客戶端成員檢視檔案，履行相應動作，並繼續流轉。管理員進行最後的處理。
(2)收文管理模組：收文管理模組顯示了所有需要簽收的公文記錄，處理人只要點選檢視，並進行相應的動作，公文就會按照流轉路線向下一個處理人傳遞。
(3)公文跟蹤模組：公文跟蹤管理功能提供對單位內部所有在流轉公文狀態的跟蹤、查詢，根據工作的實際需要可以對這些功能進行催辦、刪除和改變流程負責人等功能。
2辦公自動化系統設計
2.1系統設計目標
系統的總體設計目標是：基於計算機網路，提供一個安全可靠的、方便實用的辦公平臺，在這個平臺上，該學校使用者可以高效地處理各種公文。根據前文的使用者需求和總體設計目標，我們將某校的辦公自動化系統的具體目標歸納為：(1) 切實可行的公文處理能力;(2) 穩定性、健壯性和安全性;(3) 可定製的流程控制;(4) 可監控的辦文痕跡;(5)良好的整合功能;(6) 快速的開發過程。
2.2系統框架及功能劃分
2.2.1系統框架
初步決定將系統劃分為五個部分：
(1)公文處理，包括髮言、行文、通告、會議紀要;
(2)個人工作臺，包括個人郵箱、日程安排、修改密碼;
(3)公文監控，包括來文監控、查閱監控、公文痕跡;
(4)系統管理，包括編號管理、流程安排、許可權管理;
(5)系統整合，包括與Word和Excel在整合。
2.2.2系統功能劃分
(1)公文處理模組。公文處理模組負責處理各類公文的辦理，各類公文從起草、稽核到釋出等這些過程都是在這個模組完成的，在這個模組裡要為各種公文設定不同的外觀，每種公文的介面裡有呼叫WORD和匯出WORD的功能。
(2)個人工作臺。個人工作臺用於對本人各項工作進行統一管理。個人郵箱存放著屬於自己的各類公文，別的使用者無法進入，郵箱有提示功能，突出顯示未辦或未閱公文，郵箱裡的草稿公文是由於是自己建立的，可以刪除，已經閱讀過的成文公文也可以刪除，待辦公文不能刪除;日程安排用來安排本人的日程和活動，起到提醒的作用;修改密碼用來更改使用者個人的密碼;公文查詢用來搜尋檢視自己有許可權的公文。
(3)公文監控。公文監控提供公文從草稿到成文的辦文痕跡，記錄什麼人什麼時間對該公文做了什麼事情。
(4)系統管理。系統管理員負責辦公自動化系統的公文字號管理，使用者許可權管理和流程走向管理。
(5)資訊整合。資訊整合模組負責向該學校入口網站傳送通知公告類的公文。在學校的網路中已經實現了與門口網站的連線。
2.3系統詳細設計
2.3.1 公共模板的設計
柔性工作流著重強調系統的可重構性、可重用性和可擴充套件性，系統框架圖裡公文處理模組裡面包括了多種公文處理子模組，但這些公文處理子模組其實有很多過程是相似的，如果我們把這些功能相似的部分做成可重用的模組，即可以達到快速開發的目的又能使系統增加一定的柔性，再者，如果要修改各公文處理子模組程式碼時，只需更改模板的程式碼，而由模板生成的`其他子模組則能夠自動更新。在本文中，我們把這個模組稱為“公共模板”。
2.3.2 流程部分設計
在設計流轉機制時，本系統在處理時將所有待處理的公文進行分類，然後針對每一類公文和處理該公文的物件來確定相應的流轉規則，並在系統建模階段將該規則寫入資料庫中。
假設現有部門A、部門B和部門C，同時有公文a、公文b和公文c。針對這三個部門和三類公文，我們可以設計一個簡單的流轉規則。對於公文a，只能由部門C起草，部門 B和部門C可以接收、傳送，而部門A只能回覆;對於公文b ，部門B和部門C都能起草，但只有部門C能接收和傳送，其它部門只能回覆;對於公文c，所有部門都能起草、傳送和接收。該規則可以用相應的狀態
2.3.3 許可權管理的設計
一個OA系統中有很多參與者，而且一般也有多種公文;每一類公文針對不同的參與者又有不同的許可權。為了解決這個問題，可以引入RBAC(Role-Based Access Control)技術，先將使用者按部門和職責分組，再根據需要定義一些角色(比如起草、稽核、回覆、簽發、釋出等) ，然後將相應的組分配相應的角色。實現時要將角色設定遊離出業務邏輯，設計可配置的單獨模組，獨立於業務邏輯;而業務邏輯裡判斷的只是角色，不涉及到具體使用者。這樣設計後，人員變動、許可權更改就不會影響整個系統的應用邏輯。 3辦公自動化系統實現
3.1公共模板實現
(1)所有文件：顯示所有文件;
(2)草稿文件：顯示起草後未提交稽核但儲存了的文件;
(3)刪除的草稿文件：從草稿文件檢視內刪除了的文件;
(4)已釋出公文：已經成文並經過校辦公室釋出成功的文件;
(5)已回收公文：由於起草錯誤或傳送錯誤而傳遞到使用者郵件資料庫裡的已成為公文可以被回收，所有回收的公文被放入該檢視;
(6)預歸檔文件：在前文已經介紹，歸檔部分要與該學校的另一個系統銜接，所以本系統裡的歸檔只是預歸檔，僅僅將公文的狀態設定為歸檔;
(7)在稽核文件：所有起草完畢並已提交稽核但未成文文件。
3.2表單
我們採用了三種表單：草稿表單、稽核表單和成文表單。
(1)輸入文字：公文草稿，當用戶起草時，使用該表單，它有“本部門稽核”、 “校辦公室稽核”、“校對”等操作，
(2)處理文字：稽核公文表單，整個稽核期間的文件都用此表單，它有“獲取編號”、“提交部門領導稽核”、“提交校領導稽核”、“儲存”、“回覆”操作等。
(3)成文表單，當公文完成上述流程後，公文接收者看見的文件就是以Doc表單開啟的，它含有“關閉”和“列印”操作，除了這兩個操作外，還為祕書設計了錯發而設計的“收回”操作和因為漏發而設計的“補發”操作以及公文歸檔設計的。
3.3郵件模板的實現
3.3.1 代理
為了自動或後臺執行一些任務，我們為郵件資料庫定義了一些代理，其中有個使用最頻繁的代理mailprocess，此代理的觸發條件設定為“郵件到達之前”，主要的功能是將收到的文件按狀態分類，供不同的檢視使用。
3.3.2 應用與郵件的整合
在工作流的應用開發中，郵件和應用程式將整合在一起。當需要時，可以通過開發的應用程式向上級部門傳送一個郵件，在郵件中將申請以及連線文件以郵件的形式傳送給相關領導。
3.4資料庫實現
本系統採用使用者-角色-模組的三層安全模式，第一層為使用者，第二層為角色，第三層為系統模組。使用者和角色之間建立關係，角色和模組許可權之間建立關係，而使用者和模組許可權之間沒有直接的關係。此模型將系統的模組許可權和使用者分開，使用角色作為一箇中間層。使用者訪問模組時，通過其所在的角色對模組的訪問許可權來獲得訪問該模組的許可權，通過這種分層的管理模式可以實現有效的許可權管理。
3.5許可權管理實現
Domino在實現時可以用ACL來完成，Domino是帶有RBAC技術的群件開發工具，它的Domino Admin可以進行使用者設定和群組劃分，它的Domino Designer除了可以進行正常的程式開發之外，還可以針對某個資料庫檔案定義角色，並可以通過該資料庫檔案的ACL將角色分配給相應的使用者組和使用者。具體實現時可以在某類公文資料庫的ACL裡定義一些角色。
3.6監控資料庫的實現
監控資料庫在實現時主要是建立了三張表單和若干個檢視和一個代理。三張表單，每張表單對應一類監控資訊。在表單的上半部顯示公文的基本資訊，下半部顯示公文痕跡資訊，在下半部的這個帶附籤的表格裡，第一項標籤有“收文單位”、所有應接收人員、補發收文情況、流轉序列四項;代理用來將辦公痕跡寫到文件裡。
