1.買現成的。隨便一搜一大把，各種價位都有。這種現成的都是基於大眾的流程和需求開發的，說簡單點就是這類OA必須得按它的流程走。就是說你的OA流程必須按軟體設計的流程走，缺少靈活性。當然，一般來說，這類現成的軟體應該是足夠用了。

2.定製開發。定製開發是最好的解決方案，一般來說使用者是無法一次提出完整的需求的，即使提出了需求，也不一定是真正能解決問題。軟體開發最大的難點就是需求不明確和需求的改變。我負責本單位的資訊化建設，對這個深有感觸，並不是軟體不能實現功能，是因為使用者的需求沒有一個系統性關聯性的確認，造成功能上線後達不到使用者的目的。所以一般來說定製開發是一個漫長的過程，故而報價會很高。

定製開發從需求分析到部署上線執行，到最終的交工，個人認為沒有個一年半載是根本不行的，所以，定製開發的全程支援及響應速度是很重要的，評價一個OA系統的好壞，主要是對使用者的需求滿足程度。但是這個滿足程度可是最容易發生分歧的。

OA系統的公文管理符合《黨政機關電子公文標準 GB/T 33476-33483》，以流程搭載移動辦公技術，貫穿公文管理過程，在靈活的流程配置下，結合其它特色應用，統一撰文格式、流轉路徑，以各司其職、各負其責、協調配合的狀態，確保政令暢通，既保留了傳統公文處理習慣又提高了公文流轉效率，深入推進“網際網路+政務服務”的融合。

公文管理的關鍵點和難點

公文管理在政府和國企裡邊本身是一個複雜的體系，牽扯到的部門和人員極為廣泛，同時，公文的擬稿、審稿是否規範，簽收、執行情況如何等，傳統的公文管理是無法體現和進行跟蹤的。因此，要實現公文管理的電子化還需要多維思考，以下內容供參考：

擬稿：修改的過程應該有不同正文版本保留修改痕跡（發文單填寫、正文起草、確定是否會籤、會籤人是誰、確定傳送範圍）

會籤：需要版本保留痕跡；有許可權的人可以檢視痕跡；涉及到手寫批註（檢視正文、修改正文、提供會籤意見）

審稿：（綜合會籤意見並修改正文確定簽發方式、確定簽發人是哪位或哪些領導）

簽發：（相關領導提供相關簽發意見或退回）

編號：（對正式發文進行檔案編號）

蓋章：需要電子印章，涉及到印章管理

套紅：必須符合一定的格式

分發簽收：可以知道應閱、已閱、未閱

查閱：（內部收文單位檢視正式發文）

列印：必須能夠控制誰可以列印紅標頭檔案幾份；黑標頭檔案是否需要控制列印

執行：督辦、催辦

公文歸檔查詢：可以很方便按照時間、主題、關鍵詞、發文單位等屬性進行檢索、歸類

……