馮圣
(上海寶信軟件股份有限公司,上海 201900)
隨著互聯網、云計算、大數據、物聯網技術日新月異的發展,企業信息化建設已從信息化(IT)時代跨入數據(DT)時代,用戶對軟件項目的實施要求也越來越高。特別是大型集團型企業,要求集團層建立的軟件系統或信息平臺緊跟企業快速發展、迅速擴張的步伐,既快速又經濟地對集團內新成立或收購的分/子公司進行覆蓋實施,以實現借助信息化工具確保新進單元快速融入,按照集團統一的管理要求開展業務的目標。在此大背景下,信息系統實施內容標準化程度提高,實施時間縮短,用戶對傳統的按實施時間、人員投入、工作量收費的模式異議越來越多,集團共享型軟件覆蓋項目的收費越來越難。
工程項目管理系統作為支撐某集團下屬鋼鐵主業公司的工程項目管理業務的核心管控系統,主要支撐幾個主要生產基地的工程項目管理業務,對基建和技改類項目投資過程進行精細化管控。隨著集團收購的其他鋼鐵生產基地越來越多,集團擬將該系統提升到集團層面,更名為集團工程項目管理共享平臺:一方面,提供信息化平臺給新建或收購的生產基地使用,作為新基地工程項目管理業務的管控工具;另一方面,通過共享平臺的覆蓋,將核心業務流程和關鍵管控點統一,實現集團對各基地工程項目管理業務的集中管控。同時,為后續整個集團工程項目管理數據挖掘能力提升、接入智能分析等應用打下基礎。
按照傳統項目覆蓋的實施方式,由覆蓋單位啟動一個“工程項目管理系統覆蓋××基地”的項目,按“軟件產品”和“部署實施”進行收費,覆蓋項目結束后每年收取項目合同額一定比例的運維費。新基地對此頗有異議:既然“集團共享平臺”軟件歸屬權在集團,讓分/子公司使用不應收取軟件產品費;其次,因為是標準功能覆蓋,定制化改造的空間較小,只愿意承擔與少量系統角色權限及流程配置和數據切換導入相關的實施費用。
以“傳統的項目建設+后期運維服務”收費模式為例:假設構建一套工程項目管理系統的建設費用為300萬元,其中產品費250萬元、實施費50萬元,建設周期1年,質保期1年,項目完工后進入運維期,按質保期內合同額的5%和質保期外合同額的10%收取運維服務費。
由表1可知,按5年估算,覆蓋一家單位的建設費用為:300+15+30+30+30=405(萬元)。

表1 5年建設費用(含軟件產品費) (單位:萬元)
如果按覆蓋單元所希望的那樣不收軟件產品費,在系統實施費仍按50萬元收取的情況下,按同樣條件估算,覆蓋一家單位5年的建設費用為:50+2.5+5+5+5=67.5(萬元)。具體結果見表2。
由此可以看出,如果不收取系統建設費用,同樣的工作內容,第二種方式相對第一種方式減少了近80%的費用。在傳統收費模式中,后期運維費用按合同額比例收取,所以主要依賴前期系統建設費用。一旦前期項目建設費用降低,整體的項目金額會對實施項目的軟件企業帶來巨大影響。對于軟件企業而言,項目必然要做,問題在于如何既能滿足用戶要求,又能實現企業的盈利目標,最終實現雙贏。顯然,傳統的計費模式無法滿足該要求。
隨著互聯網的深度應用,軟件銷售模式發生轉變,急需設計出一種用戶更容易接受、軟件企業也可以使系統達成持續贏利目標的解決方案。
SaaS模式(Software as a Service)是將軟件產品放到互聯網上,使用戶不用安裝客戶端軟件即可在本地計算機使用軟件功能,并能夠幫助用戶安全保存大量數據的方式。這種方式剛提出時社會接受度并不高,當時軟件被看作資產,很難實現共享。近幾年,隨著信息技術的飛速發展,助推了軟件服務的概念,無論是買方還是賣方都不再把軟件看成一種無形資產,而是一種服務,像電力和自來水那樣即插即用、即開即用。用戶支付的不再是系統建設的產品費用,也不是系統覆蓋的實施費用,而是真正使用系統進行業務操作的使用費用,甚至是使用系統后產生經營效益的分成費用。按照這種思路,軟件以服務的方式提供,即軟件免費、服務收費的方式,而采用這種方式進行軟件計費必須做到透明化和標準化。作為共享平臺,軟件企業考慮初期成本高是自然的,但隨著覆蓋面的不斷擴大,參與者的數量越來越多,后期成本會越來越低,參與者效益放大,用戶和軟件實施企業實現雙贏成為可能。
工程項目管理系統的核心是項目,以項目為抓手,重點關注項目中投資、進度和質量安全等關鍵要素的管控。其中,可量化的主要數據是項目以及項目中與供應商簽署的采購合同和相關支付數據,合同類型包括設備、建安和服務三大類,建安合同會產生施工過程管理和完工管理相關的業務數據。
由圖1可知,工程項目管理系統中的數據源頭是項目立項信息,由項目信息產生費用相關和時間進度相關兩條主線。其中,費用相關按設備、建安和服務三大類產生估概算、合同、合同支付、財務決算等信息,投資額越高,數據量越大;進度相關按設計進度、設備采購進度和施工進度產生從設計過程、設備采購執行到貨安裝以及大規模土建工作一直到最后交工驗收的信息,工作內容越多,時間越長,數據量越大。最后是項目結束歸檔的相關結構化數據和物理文檔。就單項目系統本身而言,管理的項目越多,系統中的數據量越大。正如統計用水量和用電量,從統計系統使用情況角度,主要統計數據量的大小,而不用統計系統中所有發生的數據,因為數據無法累加,只需要抓住核心項目或合同的數量,其他數據自然成比例增長。因此,統計項目或合同的數量是統計使用單位系統使用情況的重要指標。
另一類可以量化的指標是系統使用人數。工程項目管理平臺涉及工程項目所有內外部相關方,參與者眾多,所以系統中使用人數越多,說明使用單位對系統的使用程度越高。
對于以上兩類可量化指標,可以通過系統按一定的時間段進行精確統計,作為工程項目管理共享平臺新收費模式設計的計算因子。
按內容分析中考慮到的項目、合同相關數據量和使用人員兩個維度,有兩種計費模式設計。
2.2.1 計費模式一
按單位標準收費:即單個項目多少費用、單個合同多少費用、單個使用人多少費用。每年12月中旬,按照上述三個維度統計該使用單位當年使用上述數據的數據量,再按各因素重要性配以權重計算該單位當年的系統使用費用。
以上文案例分析,某集團下屬4個基地,按傳統項目覆蓋建設模式,一個基地5年405萬元,4個基地5年總計1620萬元。圖2是各基地5年的項目數量,可以看到項目數量是有波動性的,2~3年會從低谷到高峰再到低谷。
4個基地5年的項目數量總計3824個。按照收費模式一設計,1620萬元的項目實施費用加上每年10萬元的基礎費用,4個基地5年總計1660萬元。1660/3824/5=0.08(萬元/項目/年),即每個項目800元/年。將該金額按業務發生比例分攤到項目數量、合同數量和使用人員數量上,為每個合同400元、每個項目200元、每個人200元。進而可獲得收費模式一的10年測算結果,按項目數量最多測算結果見表3,按項目數量最少測算結果見表4。

表3 1個基地10年收費模式一測算(樣本項目最多)

表4 1個基地10年收費模式一測算(樣本項目最少)
項目數量最多10年收費總計422.6萬元,項目數量最少10年收費總計114.54萬元。10年平均收費283.57萬元,4個基地平均每年每個基地約為28.36萬元。如果按照歷史使用規模推算,原先一個基地5年的項目建設費用要通過15年收回(已考慮利息等因素),從第16年開始軟件企業可實現盈利。
2.2.2 計費模式二
設置檔位模式收費:按照項目數量、投資規模(年項目總投資額)、人員數量三個計算因子計算所屬檔位,并按照每個檔位來收取年使用費用。
Ⅰ檔,項目數量<100,投資規模<50億元,人員數量<100。
Ⅱ檔,100≤項目數量<500,50億元≤投資規模<100億元,100≤人員數量<500。
Ⅲ檔,項目數量≥500,投資規模≥100億元,人員數量≥500。
檔位條件中只要滿足一項即納入該檔。
按照計費模式二計算,設置:Ⅰ檔位30萬元/年,Ⅱ檔位:50萬元/年,Ⅲ檔位:70萬元/年。按投資規模最大和投資規模最小,見表5,投資規模最大,7年總收入430萬元,超過415萬元的常規模式,可收回成本,第8年軟件企業可實現盈利。投資規模最小,8年總收入440萬元,超過415萬元的常規模式,可收回成本,第9年開始軟件企業可實現盈利。
按檔位收費更多地屏蔽了具體項目數量、合同數量和人員數量個體差異帶來的收入變化,與電信、移動話費套餐類似,采用58元、88元、128元等套餐檔位而不是按具體的實際使用量結算,以保證運營商的利益。所以,收費模式二比收費模式一對軟件企業更為有利,對于具體檔位的單價還可根據實際情況與具體客戶進行商議。
同時,在應用數據計算的基礎上還可以考慮增加一個一定比例的基礎費用,即使到年末統計時當年未發生任何“新增”業務數據,只要該單位還在系統中,仍可按系統維護和數據存儲的基本費用收取。另外,如果用戶對標準功能不滿意或認為有缺失的地方,可以單獨支付定制化費用,實施個性化的功能改造,在收取服務費時一并收取。
新模式采用軟件服務的方式,能夠讓客戶直觀感受到使用服務所負擔的費用,即用多少付多少,多用多付,少用少付,大大減少了信息化建設的當期投入。對照傳統模式,新模式節省了購置硬件服務器和應用軟件開發的費用。對于軟件企業而言,雖然承擔了一部分前期投入的硬件服務器和應用軟件的建設費用,但是從長期來看,改變了原有項目模式收費“前多后少”的弊端,新模式下系統成為一個較為穩定的盈利工具,只要系統在運行狀態,使用的用戶足夠多,每年都能保證固定的收入,從而形成軟件企業穩定的銷售收入來源,從長遠來看收益遠大于傳統模式。

表5 1個基地10年收費模式二測算(投資規模最大)

表6 1個基地10年收費模式二測算(投資規模最小)
當然,新模式也存在一定問題和風險。例如,由于數據不再存儲在企業自己的服務器上,用戶擔心數據安全,這需要軟件企業做大量投入確保數據安全。同時,由于以軟件服務的方式提供的共享平臺功能受眾面較廣,共享平臺一定會更多地考慮通用性的功能需求和產品迭代,而對個性化需求考慮較少,這與實際用戶需求正好相反。對于個性化需求,一是客戶需要單獨承擔這部分費用,而且往往費用不低;二是改造的效果往往受系統整體框架的限制,用戶體驗有所欠缺。軟件企業需承擔的最大風險在于如何確保系統有不斷擴大的用戶范圍,同時保證有穩定和長期的業務發生,以盡早消化前期建設階段投入的資金,按期收回成本,并早日轉入盈利期。
在當前形勢下,軟件定制化開發模式已逐漸顯現弊端,快速實施與響應要求帶來的軟件實施與收費模式變化,使軟件不再是一種無形資產而是一項服務,所以SaaS模式成為重要發展方向,且影響面會不斷擴大,但具體落地會因各種軟件功能、管理內容和使用方式的不同而有所差異,需要不斷地研究、實踐和探索。