OA辦公軟體篇（一）—組織架構
背景
作用
迭代歷程
具體實現
寫在最後
背景
在說組織架構之前，我們先來說說OA本身。
百度百科解釋OA為：辦公自動化（Office Automation，簡稱OA），是將現代辦公和現代計算機技術結合起來的一種新型辦公方式。
釘釘、企業微信都屬於市面上比較成熟且使用者群體廣泛的OA辦公軟體，釘釘是標準的老闆思維，企業微信則是更側重於生態圈的打造。
我們公司目前是全員都使用公司自研的OA系統來進行上下班打卡、審批等操作。在過去，不同的子公司曾經使用過不同的OA軟體：傳統醫藥公司用企業微信，因為更看重客戶維繫；網際網路公司用釘釘，因為更看重效率。將所有子公司都切換為使用自研OA的契機為：要進行統一管理及全面的數字化管理。
對於企業來說，組織架構是管理的核心部分；對於OA系統來說，組織架構按照企業規則進行管理和呈現就是OA系統的根，是把企業員工有序納入的一種重要方式，所以今天我們著重來講OA中的組織架構。
作用
OA系統的核心是組織管理，幫助組織提升績效。組織離不開人、目標、結構、管理這四大因素。目標是組織的前提條件，人員是基礎條件，結構是載體條件，管理是維持條件。
對於公司來說，組織架構和組織管理的核心，將已有的組織架構抽象到軟體中，是必要的操作和手段。
對於系統軟體來說，組織架構是軟體系統的許可權體系的重要搭建依據，軟體根據不同員工在組織中的位置給予不同的許可權，比如說普通員工對於軟體只有檢視和使用的許可權，普通管理員對於軟體有檢視和修改的許可權，超級管理員則擁有最大許可權等。
對於系統功能來說，組織架構是審批體系、日報抄送體系等功能的邏輯基礎，軟體根據組織架構的邏輯進行相應的模板處理，比如將日報抄送給所有的上級管理層檢視等；是通訊體系的核心構成部分，比如通過組織架構選擇員工發起群聊、打電話等。
對於公司員工來說，組織架構可以幫助新員工快速的瞭解公司的體系和人員構成，瞭解部門/整個公司架構。
迭代歷程
為什麼在這裡要講迭代歷程這塊呢？是因為不希望還有人在為了偷懶或者不懂的情況下迷迷糊糊的做成第一個階段的模式：純分組管理模式。
我目前在做的這個OA軟體的組織架構經歷過兩個階段。
第一個階段：純分組管理模式
僅將人放到各個分組下面裝起來。這樣做的唯一好處就是不論產品經理還是研發都能夠短暫以省時省力的方式把人放到系統中正常使用，但壞處卻一大籮筐，各個分組之間沒有聯絡—>導致組織不能形成層級關係—>缺少層級處理，無法用於系統許可權、審批流等功能。
第二個階段：組織架構模式
在組織上建立組織層級概念，使得不同部門之間能夠形成上下級部門的關係，比如運營部屬於醫療資訊化事業部；
在組織內建立職工層級概念，比如事業部的總經理是張三，副總經理是李四等；
普通員工能夠靈活管理其直屬領導，比如醫療資訊化事業部的張三由總經理直接管理，那就可以直接將其領導設定為總經理即可；
系統許可權、審批流、日誌抄送等功能可以直接使用組織架構的核心邏輯來進行功能設定和管理，比如公司第一負責人擁有超級管理員許可權，部門管理層員工均能夠擁有管理員許可權，普通員工則只有普通許可權等。
具體實現
在說具體實現之前，需要清楚我們的OA產品具體是以什麼形式去做的。
首先，從外在表現形式來說，可以採用APP或者小程式的方式來進行實現，現在很多輕量級的產品會採用純小程式的方式實現，但小程式本身對包的大小有限制，因此我們使用APP+小程式的方式來實現，使用者可以根據自己的需求自由選擇。
其次，從使用許可權上來說，普通員工和管理人員究竟是採用兩個獨立移動端來實現還是使用一個來實現，是一個值得思考的問題。我的建議是，毫不猶豫的選擇用一個移動埠實現，否則結果就是最後仍然要做埠合併和許可權重劃分，下面分別將這兩種模式做一個介紹（此處不包含Web管理端）。
（1）兩個獨立移動端（如下圖所示）：分為業務端（移動端）、管理端（移動端），普通員工僅使用移動端，管理人員使用這兩個埠。設計者這麼做的初衷是想要極其清晰的將普通員工和管理人員的使用分開，但實際上，從我的角度看，這其實就是一個“懶惰的做法”，因為本質上就是懶得將底層許可權體系搭建起來，採用了這種分埠的方式，卻給使用者和後來的產品經理都帶來了不便利。實際上因為後來我們要合併這兩個移動端，我基本上將許可權這塊進行了重構、將所有功能重新進行了梳理。
以組織架構為例，在兩個移動端的情況下分開的時候，業務端（移動端）主要實現的是組織架構的檢視和利用組織架構進行通訊的功能，管理端（移動端）除了包含了業務端的功能之外，還有部門管理和人員管理的功能。
（2）一個移動端合併實現。不分業務端和管理端的移動端，就是僅有一個OA移動端，當然它的表現形式仍然可以是小程式和APP。仍然以組織架構為例，這個OA移動端在登入上不再限制普通使用者還是管理使用者，只要是錄入資料庫中的公司員工都能夠正常進行登入，區別在於將許可權管理嵌入功能之中，組織架構的功能本身需要限制非管理人員進行部門管理的動作和人員管理的動作，檢視組織架構和利用組織架構進行通訊功能則是基礎操作。
接下來，我們進入正題，來說說組織架構的實現核心和重點。
（1）移動端、Web管理端的區別
組織架構的移動端其實行使的主要還是檢視和基本的管理操作。
而Web管理端除了基礎管理之外，還會深入的對組織架構中成員的各種許可權進行管理。許可權管理這一塊不在這一部分進行講解，會在下一章【OA辦公軟體篇（二）—許可權管理】中詳細說明。
（2）組織架構的建立和維護
建立部門的核心要素：
① 部門名稱
② 選擇上級部門，是為了將組織之間形成聯絡
③ 部門負責人：選擇部門負責人的時候需要選擇負責人的層級，層級表示此人在部門中的位置；一個部門支援多層級管理者。
（3）人員管理
除了人員姓名、電話、職位等基本資訊之外，部門需要在組織架構中進行選擇，直屬領導同樣可以進行選擇，直屬領導不會預設為順級負責人，原因為可能存在普通員工跨級直屬管理的現象，比如我們某個子公司的銷售就是由總經理直接進行管理的。
關於角色，管理層的角色才會是管理員，是什麼角色這個一是系統會按照在組織架構中的位置預設賦予，另一個是在Web管理端/移動端可以進行調整。
（4）組織架構的檢視
組織架構的檢視有兩個方式，一種是像這種“分組+跳轉頁面形式”，在當前頁面只展示第一級，要看哪一個就點選哪一個，跳轉至一個新的頁面展開檢視，一級一級點進去看就可以了。
另一種是在當前頁面可以一級一級的展開去看，需要檢視詳情再點選部門進入新頁面檢視，如下圖所示：
（4）關於通訊部分
從組織架構發起通訊，分為兩部分，一部分是電話的維護和使用，另一部分則是即時通訊的使用，因為這些對於組織架構來說不是重點，所以不再過多描述。
寫在最後：這一篇部落格除了講組織架構之外，也講了很多OA方面的點，尤其是裡面關於OA產品層面迭代的思考，值得每一個產品經理思考。從我個人來說，如何做出有價值的產品，如何在產品設計中不給別人添麻煩，也是我需要不斷警醒和思考的！