B端產(chǎn)品設(shè)計(jì)實(shí)戰(zhàn)之審批流
審批流是我們經(jīng)常遇到的問題,在進(jìn)行審批流產(chǎn)品設(shè)計(jì)的時(shí)候,需要注意哪些問題?本篇文章筆者對(duì)此進(jìn)行了分析說明,一起來看看吧。
無論是OA, HR,CRM,ERP 系統(tǒng),審批流的是我們經(jīng)常碰到的問題,比如說組織架構(gòu)變動(dòng),請(qǐng)假,出差,報(bào)銷,采購申請(qǐng)等等。那在面對(duì)一個(gè)審批流的時(shí)候,我們?cè)鯓觼磉M(jìn)行產(chǎn)品的設(shè)計(jì)呢?
我們拿一個(gè)大家在公司里面經(jīng)常會(huì)碰到的休假申請(qǐng)審批來舉例說明吧。比如說我們拿到了一些客戶的需求:
- 公司A, 需要管理一下年假的申請(qǐng),3天以內(nèi)的年假只需要直接上司來進(jìn)行審批,如果超過3天的年假需要二級(jí)審批,另外所有休假單子還需要管轄范圍的HR的審批;
- 公司B,需要管理一下年假的申請(qǐng),2天以內(nèi)的年假只需要直接上司來進(jìn)行審批,如果超過2天需要二級(jí)審批,超過5天需要三級(jí)審批;
- 公司C的需求比較簡單,就是所有年假都只需要支持一級(jí)審批。所有超過5天的申請(qǐng)都需要通知一下HR人員。
…….
這種類似的需求非常正常吧,面對(duì)這樣需求的時(shí)候我們?cè)鯓幼龀鲆粋€(gè)標(biāo)準(zhǔn)產(chǎn)品來滿足所有的需求呢?還是說我們需要滿足所有的需求嗎?
這個(gè)基于不同的情況實(shí)際上最后判斷的結(jié)果可能不同。
這篇文章就一般情況來進(jìn)行分析說明一下,首先我們先來看看需求的內(nèi)容,整體上面來說需求主要包括下面幾個(gè)部分:
- 所有的需求來說,前面的審批基本上都是直接匯報(bào)對(duì)象來進(jìn)行審批,只是基于天數(shù)可能審批的層級(jí)不一樣;
- 針對(duì)A公司來說,需求有些不一樣,一個(gè)是超過3天最后一級(jí)需要HR進(jìn)行審批;
- 對(duì)于C公司來說,超過5天的申請(qǐng)需要通知HR人員。
對(duì)于需求1,筆者覺得問題不大,邏輯合理通用。對(duì)于第二,三個(gè)需求來說,我們需要支持嗎?我們可以從下面的維度來進(jìn)行判斷:
- 需求的邏輯是否合理;
- 需求的價(jià)值有多大。
對(duì)于第二個(gè)需求來說,需要詢問HR,現(xiàn)在三天以上的單子的頻率是怎樣的?在這個(gè)頻率基礎(chǔ)上面,如果業(yè)務(wù)部門審批通過,你們拒絕的概率有多大?
對(duì)于第三個(gè)需求來說,需要繼續(xù)詢問為什么要通知HR人員相關(guān)的幾個(gè)問題,
通知到你們了有什么后續(xù)動(dòng)作嗎?是可能進(jìn)行干涉嗎?如果進(jìn)行干涉,什么樣的情況下才會(huì)進(jìn)行干涉,怎么樣進(jìn)行干涉?基于公司現(xiàn)在的情況,干涉的概率和量為多少?
你們發(fā)現(xiàn)如果深究下去,對(duì)于第二三個(gè)需求來說,事實(shí)上通知HR以及讓HR參與審批意義可能沒有那么大,根本沒有多大的可能性在業(yè)務(wù)部門同意休假的情況下,HR再來拒絕的情況,這樣處理反而讓休假申請(qǐng)審批的流程變得低效,而且單子多了HR自己也會(huì)覺得很煩(HR因?yàn)樵跇I(yè)務(wù)部門之外,審批休假的動(dòng)力還有實(shí)時(shí)性都會(huì)很差)。
HR需要的只是一個(gè)能夠方便找到多少天以上休假申請(qǐng)的記錄而已,如果有太離譜的情況,進(jìn)行一下干涉。這樣的話,可能在原來就需要的HR查詢休假紀(jì)錄功能的記錄上面支持超過一定休假天數(shù)的檢索就夠了。
如果不問青紅皂白,就來支持這幾個(gè)小功能會(huì)有什么后果呢?你會(huì)發(fā)現(xiàn)這個(gè)功能并不是很小的功能,一個(gè)小的功能要成為邏輯完整的產(chǎn)品功能都不是很容易的事情。
這里面要注意幾個(gè)點(diǎn):
- HR可能是有管轄范圍的,產(chǎn)品上面需要支持可以配置每個(gè)HR人員的管轄數(shù)據(jù)權(quán)限范圍,如果要做成通用產(chǎn)品功能,可能要基于組織架構(gòu)。這里的產(chǎn)品化配置功能會(huì)相當(dāng)復(fù)雜;
- 如果配置HR的數(shù)據(jù)管轄范圍是配在HR員工身上的,主要該HR離職或者調(diào)動(dòng)的情況,要重新進(jìn)行配置,有可能沒有人記得去修改配置;
- 如果一些單子,該HR還沒有審批,就離職的情況,這些單子怎樣進(jìn)行處理的問題;
- 如果一些單子,HR人員自己休假了,沒有審批怎么辦?
……
我這里只是舉例說明了一些例子,你們就知道產(chǎn)品的減法有多重要,一點(diǎn)點(diǎn)的增加可能帶來很多的復(fù)雜度。
如果實(shí)現(xiàn)一些邏輯不合理,或者低價(jià)值的功能,用戶不會(huì)因?yàn)槟銓?shí)現(xiàn)了而感謝你,實(shí)際上他用的可能會(huì)相當(dāng)煩,天天罵娘,然后因?yàn)椴缓糜?,又提了一大堆改善的需求或者解決方案,日復(fù)一日,年復(fù)一年,這個(gè)產(chǎn)品會(huì)這么樣?
事實(shí)上如果你透徹的理解了產(chǎn)品功能實(shí)現(xiàn)的真實(shí)效果,是經(jīng)常可以說服客戶的。(關(guān)于需求優(yōu)先級(jí)管理這塊,大家可以參考之前的一篇文章:如果定義B端產(chǎn)品的MVP)
通過需求梳理以及確認(rèn)之后,我們發(fā)現(xiàn)需求變成下面的樣子:
- 公司A, 需要管理一下年假的申請(qǐng),只需要支持一級(jí)審批,HR需要方便的查看3天以上的年假單子。
- 公司B,需要管理一下年假的申請(qǐng),2天以內(nèi)的年假只需要直接上司來進(jìn)行審批,如果超過2天需要二級(jí)審批,超過5天需要三級(jí)審批。
- 公司C, 所有年假都只需要支持一級(jí)審批。HR需要方便的查看5天以上的單子。
那我們看看主要需要哪幾個(gè)功能:
- 休假申請(qǐng),用戶可以方便的提交休假申請(qǐng),填寫休假期間,休假類型,請(qǐng)假原因等;
- 休假審批,上級(jí)可以收到休假申請(qǐng)的通知,可以方便進(jìn)行審批通過或者拒絕,拒絕需要填寫拒絕原因;
- 休假查詢,HR,經(jīng)理,個(gè)人可以進(jìn)行休假紀(jì)錄的查詢;
- 如果要做成標(biāo)準(zhǔn)產(chǎn)品,需要一個(gè)配置功能,可以配置對(duì)應(yīng)請(qǐng)假天數(shù)的審批層級(jí)??梢曰诳蛻魜砼渲谜?qǐng)假天數(shù)范圍對(duì)應(yīng)的層級(jí)。
然后我們來設(shè)計(jì)一下整個(gè)實(shí)現(xiàn)需要的數(shù)據(jù)庫結(jié)果,需要包含如下的幾個(gè)表格:
- 員工表:員工編號(hào),員工姓名,基本信息字段,匯報(bào)對(duì)象等;
- 休假申請(qǐng)表:員工編號(hào),請(qǐng)假開始日期,結(jié)束日期,假期類型,請(qǐng)假原因等;
- 休假審批表:員工編號(hào),請(qǐng)假開始日期,請(qǐng)假結(jié)束日期,審批層級(jí),審批人,審批結(jié)果,審批日期,審批備注等等(多個(gè)審批層級(jí)存放多條記錄);
- 配置表:休假類型,天數(shù),審批層級(jí)數(shù)等。
我們?cè)賮砜纯创笾碌膸讉€(gè)功能頁面:
對(duì)于所有的需求,所有的設(shè)計(jì)都沒有標(biāo)準(zhǔn)答案,無論整體還是細(xì)節(jié)的設(shè)計(jì)都要基于各種因素綜合來尋求最佳答案,筆者更希望能夠基于一些基于簡單典型案例的梳理,幫助大家找到自己思考的方法論。
作者:李東林(微信公眾號(hào):SaaS產(chǎn)品說;微信號(hào):jianguzhuxin),原ADP大中華區(qū)產(chǎn)品負(fù)責(zé)人,14年To B研發(fā)與產(chǎn)品設(shè)計(jì),團(tuán)隊(duì)管理經(jīng)驗(yàn),主導(dǎo)過多款大型企業(yè)管理軟件的設(shè)計(jì)、研發(fā)、上線,也有過2年移動(dòng)互聯(lián)網(wǎng)TO C的創(chuàng)業(yè)經(jīng)驗(yàn)。
本文由@李東林 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash, 基于CC0協(xié)議。
我覺得這里有點(diǎn)問題,客戶A不是要求3天內(nèi)一級(jí)審批,3天以上二級(jí)審批嗎,為什么會(huì)變成“只需要支持一級(jí)審批”呢?
大神請(qǐng)教個(gè)問題,審批流中,訂單申請(qǐng)?zhí)峤缓笪磳徍饲翱蛇M(jìn)行撤銷,撤銷后方可刪除,為什么不可直接刪除。
我前段時(shí)間也遇到了這個(gè)問題,我想的是有些情況下可能只是需要撤回修改幾個(gè)內(nèi)容,如果只有刪除的話,審批我需要再全部填一遍
好文,不過可能事實(shí)情況是HR部門覺得他們不審批沒有活干,然后不接受這個(gè)方案
你好能請(qǐng)教你一個(gè)問題么?
一個(gè)審批流,開始狀態(tài)是 “草稿” 可編輯刪除 , 如果審批人審批駁回后狀態(tài)是定義一個(gè)“駁回”狀態(tài)還是直接打回“草稿”狀態(tài),如果定義一個(gè)”駁回“ 狀態(tài) 又讓發(fā)起可以編輯刪除?
定義駁回狀態(tài),駁回狀態(tài)可終止,不可刪除
歡迎大家關(guān)注我的公眾號(hào)saas產(chǎn)品說
你好能請(qǐng)教你一個(gè)問題么?
一個(gè)審批流,開始狀態(tài)是 “草稿” 可編輯刪除 , 如果審批人審批駁回后狀態(tài)是定義一個(gè)“駁回”狀態(tài)還是直接打回“草稿”狀態(tài),如果定義一個(gè)”駁回“ 狀態(tài) 又讓發(fā)起可以編輯刪除?
能別copy別人的文章?
這是誰的文章?拜托弄清楚一點(diǎn)。
張口就來?
我不要你覺得我們需要什么,我們要什么你就做什么。。。哈哈
這個(gè)是大佬
給大佬打call
必須叫大佬
論如何從乙方產(chǎn)品經(jīng)理成為甲方CEO
甲方爸爸不是白叫的
挺好,寫了些workflow基礎(chǔ)的東西,workflow對(duì)B端而言屬于日常工作之一了,流程還會(huì)涉及到調(diào)整,所以也會(huì)有后臺(tái)流程的調(diào)整。
workflow基礎(chǔ)就是表單+流程+審核角色+執(zhí)行結(jié)果回收。
大佬。寫文章浪費(fèi)時(shí)間,你不要寫了
我就做過這種需求,道理客戶都懂,但是別人是給公司流程配功能的,不是給功能配公司流程的,你不按照公司流程做功能人家不會(huì)用的。
贊同
產(chǎn)品化和定制化的思維方式有差別,一看咱們就都是做乙方做慣了的人 ?
客戶之所以不用釘釘,就是因?yàn)獒斸敍]辦法滿足他們的個(gè)性化需求,你的產(chǎn)品比釘釘還少東西的話,別人沒理由用你的產(chǎn)品的。這個(gè)就是真實(shí)的市場(chǎng),不是自己yy的。