實(shí)例：園區(qū)企業(yè)的職工用戶A使用園區(qū)APP（個(gè)人注冊），向業(yè)主方申請活動(dòng)臨時(shí)用地，發(fā)起了申請流程，過程中用戶A離職，用戶B接任，因是個(gè)人手機(jī)注冊的APP，流程是中斷還是繼續(xù)，如何繼續(xù)？
因?yàn)樯婕暗较驑I(yè)主申請流程，租戶看到的流程不像傳統(tǒng)OA的流程表單、節(jié)點(diǎn)那樣復(fù)雜，我們可以就這個(gè)問題先看下OA的一般解決辦法。
傳統(tǒng)OA如何處理用戶、崗位變動(dòng)帶來的流程實(shí)例問題？
- 把離職或崗位變動(dòng)那個(gè)同事的審批處理權(quán)限換成新同事的就行，替換處理人轉(zhuǎn)交過去。
- 如果系統(tǒng)沒有這個(gè)功能 ，也可以考慮把離職同事的帳號給新同事用，處理完已經(jīng)在走的流程。
- 在后端控制臺手動(dòng)觸發(fā)用戶節(jié)點(diǎn)動(dòng)作，完成流程的流轉(zhuǎn)。
那么在園區(qū)APP中來套用上述方法會怎樣？
- 用戶A的審批權(quán)限可以在后臺轉(zhuǎn)移到用戶B，但這個(gè)交互如何實(shí)現(xiàn)呢，用戶B沒有申請的動(dòng)作，他的流程如何生成？平白無故在類似“我的流程”中生成一條不是自己發(fā)起的流程么？這個(gè)不符合邏輯。
- 用戶A賬號給用戶B使用，凡涉及個(gè)人APP應(yīng)用，這類操作都是違反用戶隱私和體驗(yàn)原則的。
- 通過后臺手動(dòng)觸發(fā)，這個(gè)就失去了APP這種手機(jī)應(yīng)用存在的意義了。
從現(xiàn)實(shí)角度來看，可以通過以下兩種方式解決：
- 通過系統(tǒng)消息推送給用戶B，用戶B點(diǎn)擊進(jìn)入消息，消息除基本說明外，提供一個(gè)確認(rèn)機(jī)制，這個(gè)確認(rèn)就是讓用戶B與用戶A建立的流程實(shí)例進(jìn)行關(guān)聯(lián)，關(guān)聯(lián)將觸發(fā)程序，將用戶B的ID與流程實(shí)例ID綁定，并授權(quán)用戶B查閱、操作默認(rèn)權(quán)限范圍內(nèi)的數(shù)據(jù)和功能。同時(shí)，拷貝一份數(shù)據(jù)提供查閱：查看歷史溝通記錄，即用戶A之前發(fā)起的會話記錄。作用就是讓其了解歷史過程。當(dāng)然這個(gè)方法中需要考慮的還有用戶B與后臺的會話界面應(yīng)該是默認(rèn)空值。
- 從開發(fā)和維護(hù)代價(jià)最小角度看，重新讓用戶B按照交互設(shè)計(jì)建立發(fā)起新的流程是最優(yōu)選擇，畢竟原有的流程數(shù)據(jù)在用戶B角度來看，數(shù)據(jù)量小、操作復(fù)雜度?。ˋPP在設(shè)計(jì)之初就以最少操作和交互為導(dǎo)向）。從企業(yè)管理層來看，同樣不涉及大量文檔、數(shù)據(jù)準(zhǔn)備，就算有一些文檔準(zhǔn)備，這也是用戶B本來就要熟悉的一個(gè)過程。
用戶A續(xù)約界面
業(yè)主用戶端A-流程節(jié)點(diǎn)
業(yè)主用戶端A-歷史溝通記錄
產(chǎn)品經(jīng)理如何選擇
選擇第一種方案，讓原有流程繼續(xù)，讓用戶B看得見歷史過程，原因有2：
- 不要讓客戶再來一次，不管是誰的原因，沒有人愿意重復(fù)走一次流程，尤其是管理層被告知某某事需要再走一次流程，雖然這個(gè)事或許很小。
- 讓流程唯一，從業(yè)務(wù)層面來，一個(gè)事情并沒有結(jié)束，也沒有重新開始，還是那個(gè)事情，換個(gè)人繼續(xù)而已。這樣客戶端和后臺的運(yùn)營人員在對信息的認(rèn)識上，是對稱統(tǒng)一的。
沒有最優(yōu)，這就是一個(gè)選擇。
