連鎖型客户,該如何用最小成本解決複雜需求

編輯導語:管理系統對於大企業或者連鎖店來説需要足夠全面的組織架構,因為連鎖店類型的涉及的分支非常密集,需要每一個層級需要清晰明瞭,管理起來才比較方便;本文作者分享了關於如何用最小的成本為連鎖型的客户解決複雜問題,我們一起來看一下。

連鎖型客户,該如何用最小成本解決複雜需求

連鎖和集團化是一個趨勢,但凡大一點的機構,隨着業務的發展,都會有向外擴張的趨勢;比如説診所會從單店變為市內連鎖店,工廠會在各地建分廠。

這也意味着我們單店版的系統不能滿足客户的要求了,那系統如何解決集團化問題呢?

一、集團的組織結構

我們先來看下工廠集團的組織結構:

一般來説總部擁有最全的組織結構,包含銷售、管理、財務、生產等各部門。

分廠可能是完整的組織,但也可能只是一個生產基地,財務獨立核算,但銷售和管理都由總部統一控制。

連鎖型客户,該如何用最小成本解決複雜需求

上面看到的工廠即便有很多分廠和子公司,一般也是由集團控股的。

但如果是門店類型的組織結構,比如説診所,連鎖店之間很可能就是戰略型合作,但實際還是各自運營的,這種關係就比較弱了。

二、集團設計模型

假設我們現在已經做完了單租户的系統,那如何在這基礎上支撐集團呢?

1. 方案1:切換各租户賬號

做集團後台是有不少工作量的,前期在人力不夠的情況下,集團管理員想要了解各分部的情況,就只能登錄不同租户的賬號查看信息。

這就面臨着一個問題:無法做統一報表,並對各分部進行橫向對比和分析;如果客户月末或者年末需要數據,那就只能讓開發從數據庫裏把數據導出來了。

2. 方案2:單租户系統數據權限控制

上面的組織結構按理是可以支持在一個系統中實現的,不同的分廠就是和總廠平級的父節點。

人員掛在不同的節點上,系統可以控制該人員只能看到自己節點以下的數據,或者有個數據權限的功能,讓客户手動設置。

連鎖型客户,該如何用最小成本解決複雜需求

但這邊帶來的問題是系統中所有的地方都要標明是哪個廠的,比如產品要增加適用分廠;設備要增加所屬分廠——這樣一來數據設置麻煩,字段冗餘,而且在用户使用時還要根據數據權限進行判斷,增加了系統複雜性。

但實際上工廠中大部分的人員是操作工等幹活的人,不需要也沒有權限看到其他廠的數據,僅為了少部分管理者的需求,把單租户系統複雜化性價比不高。

3. 方案3:搭建集團後台

比較清晰的設計方法就是在單租户的頭上再包一層集團的概念,這對於客户來説也是比較好理解的,各廠在實際生產過程中獨立運行,但管理權在集團。

連鎖型客户,該如何用最小成本解決複雜需求

這就意味着需要再做一個集團後台,看似增加了一倍的工作量,但實際上不會多很多。

我們都有這樣的經歷,新做一個系統遠比改造老系統來的簡單且不易出錯;下一節也會講到集團後台的功能,比單租户系統中的功能少得多,而且更多的是把做過的系統複製一遍,就簡單很多。

綜上所述,還是建議用集團後台的方式來處理。

三、集團後台功能設計

首先明確集團後台的使用者:財務和管理者。

那麼後台的功能主要是2大塊:報表和統一管理配置。

1. 報表

這裏的報表包括財務的,也包括運營管理的。

比如説診所集團後台的報表,有費用統計、醫務統計、藥品進銷存統計、運營統計。

這些數據就是把各分店的數據做了個彙總查詢頁面,在篩選的時候可以選全部,也可以選具體某個診所。

對原代碼的複用率是很高的。

連鎖型客户,該如何用最小成本解決複雜需求
2. 基礎數據設置

集團進行統一管控時,繞不開基礎數據的統一配置,比如診所的藥品,一般連鎖店之間的藥品是統一進貨,各店之間互相調配的。

但如果只做統一設置還不夠,診所間因為有地域的差異,藥品還不完全一樣;比如城西店有醫美項目,那肯定會增加醫美類藥品;不同診所間的價格也可能不一樣,北京店的會比小鄉鎮的貴。

連鎖型客户,該如何用最小成本解決複雜需求

所以這邊通常有3種做法:

  • 集團有統一創建權,分店無任何權力。
  • 集團有統一創建權,分店有各自修改權。
  • 集團有統一創建權,分店有各自創建和修改權。

最好是都能支持,開篇也説過不同集團的運營模式差異比較大,就算同一集團下的分店也可能是不同的模式,比如一些是直營的,一些是加盟的。

3. 基礎參數配置

基礎參數的配置也是運營管理中的重要一塊,比如會員管理,一般連鎖店之間的會員是通用的,那會員的設置規則就需要由集團統一控制了。

連鎖型客户,該如何用最小成本解決複雜需求

還有一些參數的控制,比如各分店的地址等基礎信息,儲值贈送規則,流程參數控制等;這些權力的上收能保證各分店服從集團的調配,避免私下搞運營活動。

四、總結

之前連鎖類的需求一直是用集團後台的方式來實現的,最近有人提問説,為什麼不在一個系統裏面用組織結構樹來實現呢?聽着也挺合理的。

我分析了下,還是用集團後台的方式實現成本最小,也比較好理解。

當然也有缺點:管理者在集團後台只能看到總況,想要看明細數據還是要去各系統。

但從場景的使用頻率來説,這樣的設計還是較為合理的,畢竟沒有一個完美的解決方法。

#專欄作家#

司馬特小隊,公眾號:司馬特小分隊,人人都是產品經理專欄作家。8年+互聯網資深產品經驗,多年B端產品管理經驗。具有多個從0到1的大型B端產品的孵化、重構、迭代經驗;主要教授產業互聯網產品相關的硬核知識點。

本文原創發佈於人人都是產品經理,未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議。

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 2017 字。

轉載請註明: 連鎖型客户,該如何用最小成本解決複雜需求 - 楠木軒