k3cloud對比研發(fā)提供k3cloud缺陷分析fanzh

1、目錄一、K3 Cloud 缺陷之信用控制3信用控制模型未考慮銷售返還3無法按單據(jù)流轉(zhuǎn)控制信用，導(dǎo)致操作效率低下3信用特批模型欠缺3不支持多個信用賬戶或產(chǎn)品線3可用額度計算居然不支持應(yīng)收票據(jù)3莫名其妙的“單筆限額”4可怕的“信用總額控制”.4二、K3 Cloud 缺陷之預(yù)收控制4預(yù)收管理未考慮銷售返還等異常4不支持預(yù)收款在單據(jù)間的挪用5不支持預(yù)收款的抹零5不支持多個預(yù)收賬戶或產(chǎn)品線5三、K3 Cloud 缺陷之配套生產(chǎn)類行業(yè)5寄售模式的缺陷5協(xié)同寄售模式的缺陷5寄售要貨模式的缺陷6四、K3 Cloud 缺陷之家具行業(yè)6K3 Cloud 缺乏定制選配功能6K3 Cloud 缺乏包裝規(guī)劃及包件管理功

2、能6K3 Cloud 缺乏拆圖管理功能6K3 Cloud 缺乏基于部件的促銷功能7五、K3 Cloud 缺陷之協(xié)同銷售業(yè)務(wù)7處理客戶銷售業(yè)務(wù)的缺陷7處理直運(yùn)業(yè)務(wù)的缺陷7處理多組織協(xié)同業(yè)務(wù)的缺陷7組織業(yè)務(wù)關(guān)系設(shè)計的缺陷8六、K3 Cloud 急死人的一些細(xì)節(jié)8訂單變更的急死人8可發(fā)量查詢急死人8預(yù)留變化急死人8一、K3 Cloud 缺陷之信用控制信用控制模型未考慮銷售返還在其信用模型中，未考慮“銷售返還”、“未處理的退貨”、“市場費(fèi)用抵款”等場景，在以加盟經(jīng)銷商為主的企業(yè)中應(yīng)用必然會存在問題，經(jīng)銷商認(rèn)為無法反映他們真實(shí)的可用額度，要么導(dǎo)致產(chǎn)品不適用，要么付出大量的二次開發(fā)成本。無法按單據(jù)流轉(zhuǎn)控制

3、信用，導(dǎo)致操作效率低下K3 Cloud 的信用控制時點(diǎn)是在單據(jù)的“提交”和“審核”這兩個時點(diǎn)，這是有問題。User 費(fèi)半天勁調(diào)整、好單據(jù)后，地提交、審核環(huán)節(jié)才知無法通過，要回頭去再和經(jīng)銷商溝通，再調(diào)整、單據(jù)，費(fèi)時費(fèi)力。如果一個 user 一天處理 20 張單據(jù)，一張單據(jù)多折騰 3 分鐘，每天 1 個小時就被浪費(fèi)掉了。按單據(jù)流轉(zhuǎn)控制信用，是指將單據(jù)的狀態(tài)和信用狀態(tài)剝離，和業(yè)務(wù)的推進(jìn)結(jié)合，如：在由經(jīng)銷商要貨單向正式訂單轉(zhuǎn)的過程中控制，在由正式訂單向發(fā)貨計劃或出貨單轉(zhuǎn)的過程中控制，不符合要求的就不流轉(zhuǎn)到下一環(huán)節(jié)。最主要的是在這些過程中，數(shù)量、規(guī)格、價格會發(fā)生變化，和單據(jù)狀態(tài)綁定會讓操作變得繁瑣。信用

4、特批模型欠缺K3 Cloud 中的信用特批只能針對一個客戶，無法針對當(dāng)前業(yè)務(wù)（當(dāng)前的銷售訂單或出貨單等）。導(dǎo)致為 01 訂單做的特批授信額度可能會被 02 單據(jù)使用掉了。在多人并發(fā)處理單據(jù)時，可能會存在信用控制上的，造成工作上的反復(fù)，最終結(jié)果是降低了整體工作效率。U9 中可對客戶限時提供臨時額度，也可指定某筆業(yè)務(wù)提供的臨時額度。不支持多個信用賬戶或產(chǎn)品線在自行車、電動自行車、某些小家電等“銷-維”一體的行業(yè)，經(jīng)銷商要負(fù)責(zé)對自己售出的產(chǎn)品的保修。在這種場景中涉及整車業(yè)務(wù)的授信額度、配件業(yè)務(wù)的授信額度，可以理解為 1 個客戶有多個信用賬戶，也可理解為對客戶按產(chǎn)品線設(shè)置授信賬戶。K3 Cloud 的

5、信用維中缺乏“產(chǎn)品線”，導(dǎo)致不支持上述應(yīng)用場景?？捎妙~度計算居然不支持應(yīng)收票據(jù)純工業(yè)品企業(yè)（如向主機(jī)廠等企業(yè)做穩(wěn)定的長期配套）通常有穩(wěn)定的供貨協(xié)議，一般不進(jìn)行信用控制，反倒是面向分銷的工業(yè)品或民用消費(fèi)品需要進(jìn)行信用控制。企業(yè)的客戶中，經(jīng)銷商企業(yè)多是商貿(mào)型企業(yè)，該類企業(yè)大量頻繁使用承兌匯票。在信用控制中不支持應(yīng)收票據(jù)令人匪夷所思。莫名其妙的“單筆限額”在 K3 Cloud 的信用控制維度中，有個“單筆限額”令人莫名其妙，估計是抄 U9 時只抄了一半，還有一半沒理解就沒抄?！皢喂P限額”一定是配合“押單式授信”來使用的。這是一種在合作關(guān)系非常密切的企業(yè)間的風(fēng)險控制方式。企業(yè)對客戶采取“永遠(yuǎn)押一單貨款

6、”的管理方式，客戶每次來要貨前，要把前一筆貨款清掉。顯然，采取這種風(fēng)控方式時才需要限制訂單的金額，否則會造成，客戶下一筆很大的訂單，然后關(guān)門跑路了?？膳碌摹靶庞每傤~控制”在 K3 Cloud 中，“信用總額控制”的大意是：每月為信用特批者以相應(yīng)的“特批總額度”供其進(jìn)行特批，特批者批出去的額度不得超過這個“特批總額度”，這個“特批總額度”下月初自動恢復(fù)”問題出在“月初自動恢復(fù)”，不看任何回款情況，不關(guān)心是否正確的做法是：了額度。哪個企業(yè)敢這么放水？特批者在他的特批總額度內(nèi)行使特批放水的權(quán)利；特批總額度永續(xù)流轉(zhuǎn)，特批者用完后就不能再行使特批權(quán)利了，直到客戶回款；客戶有回款時，優(yōu)先將此前享受的特批額

7、度掉；二、K3 Cloud 缺陷之預(yù)收控制信用控制一堆就算了，畢竟現(xiàn)在商業(yè)環(huán)境復(fù)雜，做賒銷的企業(yè)并不多。絕大多數(shù)企業(yè)要求經(jīng)銷商提貨時要有“掛賬款”（就是常說的預(yù)收款）。在快消品及其它民用消費(fèi)品領(lǐng)域，通常要求 100%先款，在裝備制造等 ETO定制領(lǐng)域，會有分階段的預(yù)收款。和信用控制相比，預(yù)收款的管理和控制更重要?？上?，K3 Cloud 在預(yù)收款的管理方面缺陷，簡直入目。預(yù)收管理未考慮銷售返還等異?！颁N售返還”、“未處理的退貨”、“市場費(fèi)用報銷抵款”、“途損賠償”等內(nèi)容，站在經(jīng)銷商的角度就是自己的“現(xiàn)金”，只不過企業(yè)方不會給經(jīng)銷商現(xiàn)金，通常會用來“抵訂貨款”。這部分內(nèi)容不考慮會導(dǎo)致對經(jīng)銷商的預(yù)收

8、款控制無法適用。不支持預(yù)收款在單據(jù)間的挪用預(yù)收款的挪用通常發(fā)生在訂單的優(yōu)先級發(fā)生變化。導(dǎo)致訂單優(yōu)先級發(fā)生變化的等。要求將 01 號訂單的預(yù)收款挪至 02 號訂單，01 號訂單暫緩處理?？赡苁侨必?、客戶款在 K3 Cloud 中要先較為繁瑣。掉 01 號訂單的預(yù)收款，然后再找到 02 后訂單，調(diào)出預(yù)收款分配畫面分配預(yù)收款，操作不支持預(yù)收款的抹零舉例：當(dāng)訂單金額=123456 元，首款付 30%，則訂單上預(yù)收款應(yīng)=123456*30%=37036.8 元。這種情況下，客戶經(jīng)常會要求抹零為 37000.00 元。預(yù)收款檢查時，如果沒有抹零功能就會不通過，給業(yè)務(wù)處理帶來麻煩。不支持多個預(yù)收賬戶或產(chǎn)品線

9、在自行車、電動自行車、某些小家電等“銷-維”一體的行業(yè)，經(jīng)銷商要負(fù)責(zé)對自己售出的產(chǎn)品的保修。這類企業(yè)會給經(jīng)銷商設(shè)置 2 個預(yù)收款賬戶，一個對應(yīng)主機(jī)業(yè)務(wù)，一個對應(yīng)配件業(yè)務(wù)。主機(jī)業(yè)務(wù)的銷售返金額還可以挪到配件業(yè)務(wù)的預(yù)收款金額中，反過來就經(jīng)銷商打來的款，可以在兩個賬戶中調(diào)劑。三、K3 Cloud 缺陷之配套生產(chǎn)類行業(yè)汽配行業(yè)的是為主機(jī)廠及配件經(jīng)銷商服務(wù)。汽配行業(yè)有自己獨(dú)特的業(yè)務(wù)模式，從供應(yīng)鏈角度來看，K3 Cloud 在如下方面有缺陷。寄售模式的缺陷K3 Cloud 是在客戶檔上通過【客戶分類】定義當(dāng)前客戶是否是寄售客戶，具有排它性，一個客戶要么是普通客戶，要么是寄售客戶。這意味著客戶不可以同時和企

10、業(yè)發(fā)生兩種業(yè)務(wù)。比如，客戶企業(yè)的生產(chǎn)用的部件采購走寄售模式，售后維修用備貨用的部件走常規(guī)采購模式。在這種場景下，K3 Cloud 就無法處理了，客開也不知道要怎么客開。協(xié)同寄售模式的缺陷協(xié)同寄售模式是多組織環(huán)境下的應(yīng)用模式。我方企業(yè)有總裝廠和部件廠。我方總裝廠要消耗部件廠的產(chǎn)品。我方總裝廠以寄售方式向主機(jī)廠供貨，主機(jī)廠根據(jù)實(shí)際消耗數(shù)量向我方總裝廠進(jìn)行結(jié)算，我方總裝廠要根據(jù)主 機(jī)廠結(jié)算的數(shù)量和我方部件廠做內(nèi)部結(jié)算。U9 依靠強(qiáng)大的應(yīng)用架構(gòu)能順利解決此類問題。在 K3 Cloud 中幾乎是不可能的事情。寄售要貨模式的缺陷主機(jī)廠通常給配套企業(yè)發(fā)滾動的要貨計劃。這些要貨計劃通過以 n+x 來體現(xiàn)滾動周

11、期和鎖定周期。應(yīng)將客戶的鎖定期的要貨數(shù)量轉(zhuǎn)為正式訂單，驅(qū)主機(jī)廠調(diào)撥供貨。在 K3 Cloud 中缺乏滾動的要貨計劃或無法支撐這種業(yè)務(wù)。訂單模型，更沒有以滾動要貨計劃或訂單來創(chuàng)建調(diào)撥訂單的業(yè)務(wù)，四、K3 Cloud 缺陷之家具行業(yè)K3 Cloud 標(biāo)準(zhǔn)產(chǎn)品對家具行業(yè)的特性幾乎沒有任何支持。其推出的所謂家具行業(yè)解決方案也沒體現(xiàn)?？傮w來說其行業(yè)解決方案沒有行業(yè)特點(diǎn)。K3 Cloud 在家具行業(yè)缺乏如下關(guān)鍵特性K3 Cloud 缺乏定制選配功能軟體家具要對沙發(fā)的組套、沙發(fā)的材質(zhì)、顏色、拼色、附屬品進(jìn)行選配，選配結(jié)果影響生產(chǎn)備料，影響價格。K3 cloud 沒有對應(yīng)的功能，其合作伙伴能力較弱無法開發(fā)出這

12、樣高端功能。U9 的定制選配功能在門業(yè)（美心）、等）有大量成功案例。家具業(yè)（顧家家居、等）、定制板式家具（百得勝、頂固、博K3 Cloud 缺乏包裝規(guī)劃及包件管理功能一套板式家具，一套軟體家具，要打幾個包已經(jīng)發(fā)運(yùn)了？條碼是什么？包里都裝了什么東西？哪些包已經(jīng)打好了？哪些特別是定制板式家具，要根據(jù)“拆圖”結(jié)果基于一些預(yù)置規(guī)則自動生成打包方案，指導(dǎo)車間合理打包。對皮沙發(fā)來說，因為有色差及做工一致性的要防止錯發(fā)、錯配、漏發(fā)；，一定要按原始組套保管和發(fā)運(yùn)，系統(tǒng)要控制不能拆套，系統(tǒng)對實(shí)木家具來說，同一款式家具不同生產(chǎn)批次顏色可能會有色差，應(yīng)按生產(chǎn)批次號控制組套及包件出運(yùn)；這些在 K3 cloud 中都看

13、不到。K3 Cloud 缺乏拆圖管理功能拆圖工作量大，從事多，要對拆圖的狀態(tài)和結(jié)果進(jìn)行管理；第拆圖的結(jié)果要能導(dǎo)入中形成加工規(guī)格、加工要求、下料；要能根據(jù)拆圖結(jié)果按不同物料規(guī)格及分類向經(jīng)銷商計價，形成收款通知書；在其解決方案中完全看不到。K3 Cloud 缺乏基于部件的促銷功能以定制板式家具企業(yè)為例，促銷折扣政策并不是基于成品定義（因為是純定制的產(chǎn)品），時候是按材質(zhì)定義，如：這套家具用到的“英倫白 E0 級環(huán)保板”在某個時間有折扣，或當(dāng)前家具使用的某個品牌的五金件在某個時間有折扣等。這些深度的行業(yè)特性在 K3 Cloud 中未見支持。五、K3 Cloud 缺陷之協(xié)同銷售業(yè)務(wù)處理客戶銷售業(yè)務(wù)的缺陷

14、K3 Cloud 中，客戶的收貨組織、結(jié)算組織在單頭，這導(dǎo)致它無法描述這樣的業(yè)務(wù)：中移動湖南總公司下了 1 個訂單，要求將貨分別送到長沙、常德、岳陽等，并且要將開給這些，但是由中移動湖南總公司支付貨款（客戶內(nèi)部是集采分收+集中支付）。U9 可輕松描述這樣的業(yè)務(wù)。處理直運(yùn)業(yè)務(wù)的缺陷由制造企業(yè)為服務(wù)企業(yè)，這是一個趨勢。這意味著企業(yè)要向客戶提供整合的服務(wù)而非單一產(chǎn)品。在客戶下達(dá)的訂單中，第 1 行產(chǎn)品由我方企業(yè)制造生產(chǎn)，第 2 行產(chǎn)品要求從某個供應(yīng)商處直發(fā)，第三行產(chǎn)品要求從我方某個物流中心發(fā)出。在 K3 Cloud 中，直運(yùn)業(yè)務(wù)是整單性質(zhì)而非行性質(zhì)，導(dǎo)致 K3 Cloud 無法描述這樣的業(yè)務(wù)。想二次

15、開發(fā)都無法下手。并且，K3 Cloud 的直運(yùn)業(yè)務(wù)直接向總賬生成憑證，沒有形成庫存商品收發(fā)明細(xì)賬簿，造成財務(wù)和業(yè)務(wù)數(shù)據(jù)的不一致，給對賬造成很大困擾。處理多組織協(xié)同業(yè)務(wù)的缺陷典型地，企業(yè)處于合理訂單，再將訂單轉(zhuǎn)到設(shè)置在工廠。的需要，在英屬維京群島（BVI）或設(shè)置殼公司（Pr 公司）專門接海外客戶的總部（或銷售公司），總部再將訂單轉(zhuǎn)到設(shè)置在東莞的總裝工廠及部裝從稅務(wù)及審計的要求出發(fā)，要求上述業(yè)務(wù)鏈條中的購銷合同完整、庫存收發(fā)單據(jù)完整、庫存商品賬簿完整，一套人馬多塊牌子，操作U9 有很多這樣的客戶。簡便。K3 Cloud 中只能做O 這一步固定的協(xié)同，無法再做拓展，要二次開發(fā)幾乎是不可能事情。組織業(yè)

16、務(wù)關(guān)系設(shè)計的缺陷來看如下的一個經(jīng)典場景：有 3 個工廠向各地供貨。3 個工廠的產(chǎn)品各不相同，A 工廠生產(chǎn)面包+果醬，B 工廠生產(chǎn)甜餅+果醬，C 工廠生產(chǎn)甜餅+面包。因地域的關(guān)系，1 的面包、果醬要向 A 工廠訂貨，甜餅要向 C 工廠訂貨；2 的面包向 C 工廠訂貨，甜餅+果醬要向 B 工廠訂貨；好復(fù)雜的關(guān)系呀，沒辦法，為節(jié)省物流成本，必須就近供貨。每次錄入訂單時都要人工選擇嗎？操作員會瘋掉了。在 U9 中可預(yù)先定義這種供應(yīng)關(guān)系，在 K3 Cloud 中對此為力。六、K3 Cloud 急死人的一些細(xì)節(jié)訂單變更的急死人K3 Cloud 訂單變更單要人手工選擇要變更的字段，操作繁瑣易出錯；K3 Cl

17、oud 訂單變更單無法一覽看出字段變更前和變更后的值；U9 是讓你在原訂單畫面直接改，U9 象 BBflash 一樣了你的修改行為，自動生成 1 張訂單變更單，審核后變更內(nèi)容生效，變更單上有變化的字段變更前后的內(nèi)容能直觀顯示。操作流暢，傻瓜都會；可發(fā)量查詢急死人企業(yè)在處理經(jīng)銷商訂單時一是看有沒有貨，二是看款夠不夠。有貨有款的訂單就通過，缺貨缺款的就要和經(jīng)銷。這個過程越簡潔工作效率就越高。U9 是在參照畫面就直接觀地展現(xiàn)多工廠可出貨物的可發(fā)量，有貨沒貨一目了然，沒貨的就不要錄入訂單了，商早晚還得刪除或關(guān)閉掉。K3 Cloud 是不管有貨沒貨，必須將經(jīng)銷商要的全部貨都錄入訂單保存了，然后才能按下 1 個按鈕“可發(fā)量查詢”，發(fā)現(xiàn)有缺貨的，再和經(jīng)銷商溝通后人工刪除，是不是很折騰？訂單量大的話，一個訂單多處理 3 分鐘，一天浪費(fèi) 1個時很輕松，一年浪費(fèi)數(shù)百個小時呀，相當(dāng)于一年給 1 個員工浪費(fèi)了十幾個到幾十個“帶薪折騰假”。預(yù)留變化急死人計劃不如變化?？傆幸恍┮馔獾?/p>