標籤: 供應鏈管理

【軟體開發、系統開發】多執行緒多任務存取相同變數,隔離保留各自任務的值 ThreadLocal 技術講解

      在講解幾篇關於多工、多執行緒、平行作業的技術文章後,想來談談另外一個深入的關鍵多多執行緒的問題,那就是多執行緒(多工)作業模式下,如何存取相同變數值,而且又希望各自的執行緒對相同變數又有各自的“值”。

      在 .Net 技術平台下,有個 ThreadLocal<T> 的泛型類別,這個類別可以專門用於有多個執行緒需要共同存取一個變數,但每個執行緒對這個變數的值,又個別記錄隔離儲存,互不影響。我舉個例子來說明,有執行緒A、執行緒B、執行緒C、執行緒D,這四個執行緒平行作業,將共同存取一個變數 X ,但在執行緒A存取變數X時,設定值為 10;執行緒B存取變數X時,設定值為 20;執行緒C存取變數X時,設定值為 30;執行緒D存取變數X時,設定值為 40; 在執行緒A設定 X變數值為 10時,並不會影響到 執行緒 B/C/D 各自設定的 X 變數值。

     一樣在此,我透過一個程式範例來進行實例說明,這個專案類型就簡單用 Console 控制台類型來引導…

完整程式碼如下:

namespace NetQna.Demo
{
     /// <summary>
     /// ThreadLocal 示範教學(網智數位-軟體開發)
     /// </summary>
     public class Program
     {
         /// <summary>
         /// 所有執行緒共同存取的變數值
         /// </summary>
         static ThreadLocal<int> X = new ThreadLocal<int>();


        static void ExecThreadTask(object obj)
         {
             ThreadEntity currThread = (ThreadEntity)obj;
             //在各自的執行緒環境設定 X 變數值,觀察各自的執行緒下,X 變數值各自記錄
             X.Value = currThread.ThreadValue;


            //顯示出 目前所在的執行緒 的值
             Console.WriteLine($"現在的執行緒 ID:{Thread.CurrentThread.ManagedThreadId},{nameof(X)}變數值為:{X.Value}。");
             //顯示出 目前所在的執行緒 的值
             Console.WriteLine($"現在的執行緒 名稱:{currThread.ThreadName},{nameof(X)}變數值為:{X.Value}。");
             Console.WriteLine();
         }


        static void Main(string[] args)
         {


            Dictionary<string, int> threadABCD = new Dictionary<string, int> { { “A", 10 }, { “B", 20 }, { “C", 30 }, { “D", 40 } };


            //分別啟動 A、B、C、D 執行緒,並執行 存取 X 變數值
             foreach (var t in threadABCD)
             {
                 ThreadEntity obj = new ThreadEntity { ThreadName = t.Key, ThreadValue = t.Value };


                //Action<string, int> action = ExecThreadTask(t.Key, t.Value);
                 Thread currThread = new Thread(ExecThreadTask);
                 currThread.Start(obj);


                //這邊我刻意停頓 1 秒,以利顯示各自執行緒
                 Thread.Sleep(1000);
             }


            Console.Read();


            X.Dispose(); //X 變數 釋放
         }


         public class ThreadEntity
         {
             public string ThreadName { get; set; }
             public int ThreadValue { get; set; }


        }
     }
}

程式說明講解

1

一開始我宣告一個屬性變數為 X ,也就是今天講解主要的類別 ThreadLocal,
待會就是用 這個 X 變數,來讓所有執行緒進行存取設定 X 變數值。


2

宣告一個帶有 object 參數的方法,待會就是要讓所有執行緒去各自執行這個方法,這個方法主要我將  object 型態 的 參數 obj 轉型為我自己宣告的類別 ThreadEntity 類別(PS:因為 Thread 建構子對應的方法的參數只能是 object 型態,所以我透過轉型來避開這限制)。

public class ThreadEntity
{
     public string ThreadName { get; set; }
     public int ThreadValue { get; set; }


}

最關鍵的地方,我在這個方法設定了各自執行緒要對應的 X 變數值

//在各自的執行緒環境設定 X 變數值,觀察各自的執行緒下,X 變數值各自記錄
X.Value = currThread.ThreadValue;

3

我這邊分別建立 A、B、C、D 四個執行緒,然後分別設定他們待會要指定 X 變數的值為(10、20、30、40)。

程式執行結果如下圖
d

可以看出 A、B、C、D執行緒各自維護自己 X 變數的值。


參考文章
C#多工作業與平行處理技術講解
1.透過 Thread 類別撰寫多執行緒多工作業。
2.透過 Delegate 委託支援的方法,撰寫非同步任務。
3-1.透過 Parallel 類別操控多任務平行作業(一)。
3-2. 透過 Parallel 類別操控多任務平行作業(二)。
4.使用 Task 自行控制非同步任務作業。
5.在非同步作業時,如何取消非同步任務。
6.多執行緒多任務存取相同變數,但卻各自隔離保留各自任務的值。
7.非同步存取變數的問題。
8.非同步資源鎖定解決方式。



網智數位-軟體開發(軟件開發)
針對各特殊產業都可以量身定做符合貴公司的需求,別人無法克服的就是我們的挑戰
業務合作、軟體委外開發
業務窗口:allen@netqna.com
聯繫電話:0920-883-870
公司電話:02-55991310
公司地址(業務營運處):台北市中山區錦州街 25 號 5 樓
skype: netqna
line:netqna
微信:netqna
黃先生 Allen

ERP 各種計劃階段的差異

      企業資源規劃(ERP)就是通過資訊科技技術等手段,實現企業內部資源的共享和協同,克服企業中的官僚制約,使得各業務流程無縫平滑地銜接,從而提高管理的效率和業務的精確度,提高企業的盈利能力,降低交易成本。 ERP系統是由計劃驅動的。它有5個層次:經營規劃、銷售與運營計劃(生產規劃)、主生產計劃、物料需求計劃和車間作業計劃(或採購作業計劃),如圖1所示。其中,經營規劃和生產規劃屬於宏觀層次,主生產計劃是宏觀向微觀過渡的層次,物料需求計劃是微觀計劃的開始,車間作業計劃(或採購作業計劃)則是​​進入執行或控制計劃的階段。通常把前3個層次稱為主控計劃,說明它們是製定企業經營戰略目標的層次。

christina-wocintechchat-com-Q8IgAlmHAUA-unsplash

    一、經營規劃

    企業的計劃是從長遠的戰略規劃開始的,這個戰略規劃在ERP系統中稱為經營規劃。企業的經營規劃是計劃的最高層次,是企業總目標的具體體現。企業的高層決策者,根據市場調查和需求分析、國家有關政策、企業資源能力和歷史狀況、同行競爭對手的情況等有關信息,制定經營規劃。它包括在未來2~7年的時間內,本企業生產產品的品種及市場定位、預期的市場佔有率、產品的年銷售額、年利潤額、生產率、生產能力規劃、職工隊伍建設等。

    企業經營規劃的目標,通常以貨幣或金額表達。這是企業的總體目標,也是ERP系統其他各層計劃的依據。所有層次的計劃,歸根結底,只是對經營規劃的進一步具體化,而不允許偏離經營規劃。經營規劃的製定要考慮企業現有的資源情況以及未來可以獲得的資源情況,具有較大的預測成分。

    二、銷售與運營計劃

    銷售與運營計劃S&OP(Sales and Operation Panning)也叫生產規劃,是根據經營規劃的目標,確定企業的每一類產品在未來的1―3年內,每年每月生“多少及需要哪些資源。其作用是:

    1. 將經營規劃中用貨幣表達的目標轉換為用產品系列的產量來表達。

    2. 制定一個均衡的月生產率,以便均衡地利用資源,保持穩定生​​產。

    3. 控制拖欠量(對MTO)或庫存量(對MTS)。

    4. 作為編制主生產計劃(MPS)的依據。

    此外,銷售與運營計劃還要整合規劃過程。這是因為,銷售規劃並不一定和生產規劃完全一致。例如,有些產品的銷售規劃要反映季節性需求變化,而生產規劃則要考慮生產線的均衡生產。另外,在不同的生產銷售環境下,生產規劃的側重點也會不相同,例如,對現貨生產(MTS)類型的產品,生產規劃在確定月產率時,需要考慮已有的庫存量。如果要提高成品庫存資金周轉次數,年末庫存就要低於年初,那么生產規劃的月產量就必須低於銷售規劃的預測值,不足部分用消耗庫存量來彌補。

    三、主生產計劃

    主生產計劃MPS(Master Production Schedule)是以生產計劃大綱為依據,按時間段計劃企業應生產的最終產品的數量和交貨期,並在生產需求與可用資源之間作出平衡。

    四、物料需求計劃

    物料需求計劃是根據主生產計劃對最終產品的需求數量和交貨期,推導出構成產品的零部件及材料的需求數量和需求日期,直至導出自製零部件的製造訂單下達日期和採購件的採購訂單發放日期,並進行需求資源和可用能力之間的進一步平衡。

    五、車間作業計劃與採購作業計劃

    車間作業計劃也叫車間作業控制PAC(Production Activity Control),是企業計劃的最底層。其任務就是根據MRP生成的零部件生產計劃編制出工序排產計劃。對於採購件,則編制出物料採購計劃,但採購作業計劃不涉及企業本身的能力資源。

    總之,ERP任何一個計劃層次都應包括需求和供給兩個方面,也就是需求計劃和能力計劃。要進行不同深度的供需平衡,並根據反饋的信息,運用模擬方法加以調整或修訂。上一層的計劃是下一層計劃的依據,下層計劃要符合上層計劃的要求。如果下層計劃偏離了企業的經營規劃,即使計劃執行得再好也將是沒有意義的。整個企業遵循一個統一的計劃,只是ERP系統最基本的要求。劃分ERP系統計劃層次的目的是為了體現計劃管理由宏觀到微觀、由戰略到戰術、由粗到細的深化過程。計劃和控制是ERP的目標手段。計劃是為達到一定的目標而製定的行動方案;控制是為保證計劃完成而採取的措施。

(其他參考文章)
MPS主生產計畫專文介紹(一)
MRPⅡ/ERP 能力需求計畫原理
庫存管理-概念與釐清
庫存管理探討-VMI
真正的庫存量形成探討
庫存管理的中樞控管法則(上)
庫存管理的中樞控管法則(下)
BOM表管理與設定﹣輔料是否需輸入BOM
何謂 進銷存、ERP、WMS?三者差異性【軟體開發、軟件開發、程式設計】
ERP 產品成本管理與計算
庫存量正確性衡量法則
粗能力需求計畫(RCCP) – 專文介紹
ERP 系統的淺談與優勢
庫存目標6大範疇

網智數位-軟體開發(軟件開發)
針對各特殊產業都可以量身定做符合貴公司的需求,別人無法克服的就是我們的挑戰
業務合作、軟體委外開發
業務窗口:allen@netqna.com
聯繫電話:0920-883-870
公司電話:02-55991310
skype: netqna
line:netqna
微信:netqna
黃先生 Allen

 

軟體公司與網路(互聯網)公司之差異性(軟體開發、客製化軟體、程式設計)

    在現行許多軟體公司與網路(互聯網)公司在客戶面、獲利來源、以及市場區隔性、差異性,讓很多人有點分不清楚,這兩者在本質上是有一定的落差,不論是商業模式、獲利來源、團隊人才取捨,而 Allen 我自2003年進入.NET程式平台開發領域(早起是開發 LAMP,Linux + Apache + MySQL +PHP),這快15年的.Net技術迭代更新,我能跟隨學習的就盡力,當然也犧牲了生活品質質量,我期間經歷過專業的管理軟體公司、網路公司,也有國內上市企業服務、傳統產業擔任資訊部經理,深感其中的差異,撰寫文件分析兩者的聯繫和區別,供其他疑惑者的朋友可以進行思考我的論點(當然不一定是對)。

LINE_ALBUM_AI產生圖_240212_750

IT 技術的選擇差異性

(一)管理軟體公司著重於業務實現、產業領域知識的導入、企業流程的整合,網路公司著重於高並發、高可用、使用者體驗、操作介面友善性等;在企業管理軟體的使用者一般是企業或各工廠各部門行政人員,一個大公司也不過10~300個使用者同時上線,所以相對一定是對與企業的業務流程的實現與整合相對要求高,這樣才可以節省人力、降低人事成本,而不是增加成本,當然有的管理軟體提供了大量的簽核審批的機制、功能,每走一個流程,每確認一個步驟(下訂單,發貨,產生發票,請收款)都要審核,我個人認為這樣的管理軟體是增加使用者的成本,進而降低效率,我們把企業、工廠當成一個合作的整體存在,業務部負責下訂單,生產部負責在規定的時間完成訂單生產,採購負責及時的購買所需要的生產物料,這是一個密不可分的整體化運作,任何一個環節卡住會造成訊息溝通的不流暢,更甚至會導致生產停滯、呆料,我在多年以前,我們在網上註冊一個帳號,輸入帳號、密碼等,提交時提示電子郵件必須輸入,這時我們輸入的密碼也會被清空,對於非常重視使用者經驗的網路公司,勢必一定會考慮到這種案例,系統需要幫忙我們記住之前輸入的密碼,這時只需要輸入電子郵件即可再次發送。

(二)單純的軟體開發公司用的技術相對來說一般是比較老的,穩定的,成熟的技術。比如.WCF、Windows Forms、WPF、Web Forms、ASP.MVC,而網路公司走向一般會追求新的技術,比如Spark、Redis、Micro Servie(所謂的微服務)、Hadoop、Node.js 等。單純軟體公司會使用 SQL Server Analysis Services作為 OLAP 的分析工具,而新的網路公司可能會採用 Spark + Hadoop 等大數據技術來達成實作的可能性,如果工程師在喜歡搞技術創新的管理軟體公司上班,常常會活的比較痛苦。如Linq to SQL出了沒多久,Entity Framework出現,Silverlight,WPF後來也是逐漸從公眾視野中消失。 ASP.NET MVC的出現,大批Web Forms程序員找工作變難了。現在ASP.NET Core 的又出現,不曉得會不會導致ASP.NET MVC 程式設計師的資訊焦慮症候群。

(三)管理軟體公司的技術升級常常來自於內部本身的程式開發人員,而網路公司的技術變更多的來源於客戶、業務需求。正所謂成也蕭何,敗也蕭何;但處於軟體行業頂端的軟體公司創造技術解決問題,提供開發工具維持企業利潤,中小公司則應用技術解決業務問題。軟件業相當頻繁的技術更新,造成了大批老技術程序開發人員失業,從而進一步增加了軟件公司的生存成本,例如現在市場上幾乎找不到或是很少能找到VB6 或 Cobol 程式設計師,還有一些我們沒有聽說過的技術(他們的確存在於現實的公司中、例如 cobol,今年我們就有要評估一個大型系統是 cobol要轉變為.Net平台的評估案),VB6 開發人員要嗎失業,要嗎轉型,那麼軟體公司呢,大量的用Delphi開發人員的,非常優秀的VB6 開發還是需要人員維護,軟體公司面臨兩個選擇:要嗎用新技術重寫,要嗎養幾個老開發人員一直做維護。軟體公司的老闆都是人精,不可能將公司的未來受一兩個程序開發人員控制,所以就用前一種方案,用新技術改寫,這樣的目的主要是好招人,老程式員離職了再招新開發人員,努力將公司的命運控制在自己手中。以前我們公司的C/S(Windows Forms、WPF)程式開發人員常常會擔憂以後找不到工作,當時身為他們的直接主管,常常需要體會他們的這種壓力。技術上要將一些通用的重要的技術方案交給他們做,讓他們建立信心,同時也給他們安排一些熱門技術的培訓課程,作為管理人員,也需要對他們的未來負責,對他們的績效給予一定的相對優質的評定。網路公司的IT技術變更,比如大數據的需求,數據的來源形式和格式多種多樣,原有數據挖掘方案解決不了,迫切需要做技術變更以適應這種變化。於是就有對Hadoop,Spark這種大數據技術的需求,更厲害的網路公司甚至於重建一套大數據平台,以保證一直處於行業領先地位。

團隊組織文化的差異性

(一)軟體公司適合純技術人員生存,網路公司則相對重運維+技術。比如上一節我提到的緩存技術,網路公司將此發揚光大,提供一整套的分散式解決方案(Redis,MongoDB)。程式開發人員不僅僅要會調用API,還需要Deploy部署服務器,理解它們的內部運作機制原理,而在軟體公司,為了增加產品的高可用性,我們提供集群,鏡像,資料庫複寫,資料庫記錄檔(日誌)等技術,我們可以保證系統 7*24 不間斷運作。而網路公司對此要求更高,他們還要求高並發。我們知道資料存在硬碟上,讀取資料或保存資料是一個很合理的操作,管理軟體增刪查詢修改都是這樣模式,但網路公司對此還不滿意,因為多人並發的存在,資料必須要保存在記憶體中才能滿足快速的高並發地需求,當然還有高可擴展性,為了升級管理軟體,我們停止伺服器程式,或者直接重新啟動下機器是很常見的操作,但網路公司對此零容忍,他們要求更新系統時,不能停止服務,或是非常短暫(秒級)的停止服務。後者要求系統可以做到熱插撥,這跟USB接口做到熱插撥並成為業界標準是同一個趨勢,我們知道Oracle升級補丁包時,可以不用停止資料引擎服務,這個特性對網路公司非常重要(SQL Server用鏡像技術也可以達到此目的)。總體來說,管理軟體公司只需要把技術做好,而互聯網公司要求在技術之外,還需要了解運維層面的知識。

( 二)單純的軟體公司的同事頭腦相對固定(當然也聰明,能從事軟體業,相對一定是邏輯思維能力一定不錯),網路公司則靈活一些,它們存在的理由是創新。管理軟體作為一種管理思想的軟體整合實現,應該是一種管理模式,方法和思路與流程的固化,不允許或是少量允許變化。試想一下,規定的流程不跑,數據沒經過運算,自然沒有想要的結果。舉例說明,大部分的ERP軟件約定的流程,客戶下訂單,物控部跑MRP計劃,產生物料採購需求和半成品的加工需求,最後成品完成入庫,向客戶發貨,財務結算等。這是製造業ERP的基本流程,不過貿易公司的ERP則可以不這樣跑,可以直接向供應商下訂單,然後發貨到客戶,自己甚至都不用租賃倉庫,直接提供供應商到用戶的端到端(直運業務)業務模式。這些思路決定了管理軟件不需要創新,按照約定俗成的或是上司規定的流程完成即可。常此在這樣的思路下工作,人會失去創新血液。管理軟件的員工常常會被產品設計人員的思路導向,創新會自食惡果。而網路公司則相對充滿著創新的動力。

(三) 在管理軟體公司是人才培養的搖籃,通常軟體公司規模也偏小,但確實是產生高級工程師的地方。網路公司因為業務變更頻繁,技術更新迭代快,不適合純技術人員生存,常常是技術人員走管理,轉業務銷售的地方,在軟體公司有明確的人才培養方案,一個資深開發人員帶幾個年輕程式設計師,像老母雞帶小雞一樣,一步步教導這個怎麼實現,那個如何設計會更有效率一些,直到新人變老手,初級程序員變中級工程師。比如我們在管理軟體公司學到的,借助於緩存可以提高效率,改善性能,用反射技術可以做成插件式系統,用動態語言可以把系統做成可擴展的,這些技術隨著程序員年歲的增長,慢慢學會並靈活應用。網路公司因為技術變更快,Web 2.0、雲計算、物聯網、車輛網,大數據,技術更新非常頻繁,只有達到壟斷級別的公司才可以生存。我們都是凡人,能進入各個領域的壟斷級別的公司都非常不容易,即使進入,項目迭代周期短,KPI壓力大。 (我這裡說的適合於中小公司,大公司不適合於此小節描述。)

銷售模式與市場競爭差異性

(一)單純軟體公司的人員相對比較起來缺少銷售觀念,而網路公司員工更多的會關注到到商機,常常會考慮把技術轉化為價值,而管理軟體公司的員工則比較缺乏市場的積極性、參與了解動能不足,他們可能還在研究新版本的開發工具有哪些產品特性,期待以拖放的方式就能設計出工作流的軟體廠商,所以如果能把幾年工作的成果抽象提煉出來,形成一些公共的開發類庫,方便以後的開發,這是一個小小的進步。進一步的,能把管理軟體中相同的操作界面和模式總結出來,做出一些相對通用的界面和控制箱,比如資料的輸入Entry,資料的查詢Query,資料的清單 List,設計報表Report,資料查找Lookup,自定義查詢Query等,初步形成一個開發框架。再進一步,我們用自己提煉的開發框架,用自己參與和理解的技術理念,做出一套產品,這也算是一個小小的進步。技術進步的每一個階段都可以為你的職業發展帶來無窮的好處。熟練的程序員再也不擔心找工作沒人要。成為一個領域的資深開發人員,可以為自己贏取技術主管或經理的職位。做出一個領域或行業的產品,如果在合適的時機碰上會做市場的銷售人員,創業也是非常有可能的,記得一句話,夢想是要有的,萬一實現了呢?

(二) 網路公司相對容易產出新概念,新名詞以吸引大眾眼球,以此創造概念經濟,而單純軟體公司相對比較墨守成規,比如我在2006年所經歷的Web 2.0,那時滿大街的都是這種宣傳材料,沒過多久這種概念就過時了。正如現在鼓勵創業氛圍,雲計算服務,物聯網、車聯網、智慧家庭以及大數據等等,相信不久也會從我們的公眾視野中消失,當然也可能產生非常大的市場規模,但我相信市場一定會大洗牌,取而代之的是大批的網路公司、物聯網消失不見,而管理軟體公司則很少會這樣,MRP,ERP還是上世紀90年代的概念,現在仍然適合於企業管理軟體的設計思路。儘管ERP之後還有產生ERP II概念,不過也不怎麼流行。管理軟件公司相對務實,能把物料需求計劃(MRP)跑流暢,基本上公司的信息化水平就上了一個大台階,也不會再去追求管理創新。金融也是一個不適合創新的領域,記得 一個經濟學家說過,我們應該將所有的經濟學家從社會上去除,因為金融改革就是擾亂社會秩序。國際金融炒家索羅斯的至理名言也曾表述,我們就是為了創造一種假象,然後在人們認識到真相前提前退出遊戲。

     在這幾天連假看到網路詢問未來趨勢、以及思考許多資深從業人員後,隨意整理撰寫的文章,希望新的2017年有嶄新的開始,軟體業、網路業、IT技術 我依然熱愛,一生與它為伍。

網智數位-軟體開發(軟件開發)
針對各特殊產業都可以量身定做符合貴公司的需求,別人無法克服的就是我們的挑戰
業務合作、軟體委外開發
業務窗口:allen@netqna.com
聯繫電話:0920-883-870
skype: netqna
line:netqna
微信:netqna
黃先生 Allen

ERP 系統的淺談與優勢 (軟體開發、客製化軟體、程式開發)

ERP已經是一個成熟多年的老詞彙,而ERP的全稱是Enterprise Resources Plannig,中文又叫企業資源管理計劃系統;它是基於先進的企業管理理念下研發出來的一款應用資訊花技術系統,它可以對整個企業與組織,來實現資源整體化、一致化管理的企業管理工具。

LINE_ALBUM_AI產生圖_240211_46

它自從在90年代後期ERP從美國流傳到台灣,為國內的傳統企業管理體制改革注入了一種新的活力。目前ERP已經成為了各大中型企業不可或缺的重要管理工具,也是企業是否進行資訊化、系統化和企業化現代化的的重要衡量標準。 ERP專案是一個企業管理系統工程,而不是一般意義上的企業管理資訊系統工程或者是企業資訊化建設工程,這是因為整個管理系統不但基於ERP、系統工程和資訊技術等現代科學技術的思想、原理和方法,而且還從本質上充分地體現了企業應用ERP與開展企業管理創新、推進企業管理現代化和提高企業競爭力的必然關係。

1、銷售:銷售部門接客戶採購計劃,根據客戶要求,查看是否有庫存,有-即給客戶發貨;無-即下生產任務給生產部門,要求安排生產;待成品機器完工後,即可給客戶發貨。

2、生產:生產部門接銷售部任務,向生產車間下達生產任務,可依據庫存,向採購部門請購有關零部件。完工後,入庫供銷售部發貨。

3、採購:採購部門依據所接請購任務和庫存情況,向材料供應商採購料品。

4、庫存:倉庫根據零部件的安全庫存量向採購部門請購零部件。依據生產車間的生產領料單給車間發料。

5、財務:進行成本計算、稽核財務支出是否有異常。

我簡單的來說,ERP 就是一個企業資源計劃系統.它是由美國著名的計算機技術顧問和評估集團Garter Group 公司提出的一整套企業管理系統體系標準,是指建立在資訊技術基礎上,以提高企業資源效能為系統思想,為企業提供業務集成運行中的資源管理方案。

所以事實上 ERP 絕對並不單單是一個軟件工具,它的核心是一個個先進的管理理念,它的出現實現了企業資源的整合、分析和高效的利用。通過它我們可以將公司的人、財、物、產、供、銷及相應的物流、信息流、資金流、管理流、增值流等緊密地集成起來,實現資源高效化和效率化,這就是ERP。

那麼我們再來想想,ERP 具備哪些明細優勢呢?

1、實用性

企業實施ERP系統的本質就是提高企業的核心競爭力,為企業實現效益最大化,這些特點都可以體現ERP的本質。 ERP的宗旨就是對企業現有的人力、物力、財力等資源進行綜合管理優化,ERP系統對各部門進行協調管理,以市場需求為導向開展企業的一切營銷活動,幫助企業實現核心競爭力的提高,效益最大化。

2、整合性

ERP最大的特色是使整個企業信息系統整合,比傳統單一的系統更具功能性。

3、彈性

採用模塊化的設計方式,使系統本身可因企業需要新增模塊來支持並整合,提升企業的應變能力。

4、集中的數據資料儲存

將原先分散企業各角落的數據整合起來,使數據得以一致性,並提升其精確性。

5、便利性

在整合的環境下,企業內部所產生的資料訊息透過系統將可在企業任一地方取得與應用。

所以我來總結以下論述,ERP提供了一個跨地域、跨部門甚至跨企業實時整合分析信息的企業管理應用。它可以在企業資源最優化配置的基礎上,協助企業整合日常的管理需求和所有的運營,包括了財務管理、進銷存管理、生產計劃及管理、物料管理、銷售與分銷等主要功能模塊,以達到提高目標運作效率的效果。

(其他參考文章)
MPS主生產計畫專文介紹(一)
MRPⅡ/ERP 能力需求計畫原理
庫存管理-概念與釐清
庫存管理探討-VMI
真正的庫存量形成探討
庫存管理的中樞控管法則(上)
庫存管理的中樞控管法則(下)
BOM表管理與設定﹣輔料是否需輸入BOM
何謂 進銷存、ERP、WMS?三者差異性【軟體開發、軟件開發、程式設計】
ERP 產品成本管理與計算
庫存量正確性衡量法則
粗能力需求計畫(RCCP) – 專文介紹
ERP 系統的淺談與優勢 (軟體開發、客製化軟體、程式開發)

網智數位-軟體開發(軟件開發)
針對各特殊產業都可以量身定做符合貴公司的需求,別人無法克服的就是我們的挑戰
業務合作、軟體委外開發
業務窗口:allen@netqna.com
聯繫電話:0920-883-870
skype: netqna
line:netqna
微信:netqna
黃先生 Allen

庫存目標6大範疇(程式開發、程式設計、軟體開發、系統開發)

      這一個月去一家經營40幾年的代工廠,委託我們協助分析他們現行 ERP系統,很多庫存數量都一直無法精確,當然這邊所謂的精確,不完全是軟體系統庫存數字的正確,或進行盤盈盤虧進行調整數字動作,而是他們想要一個方式可以進行一個針對各種產品品項設定一個好的庫存量控制,我就詢問他們如何定義跟衡量一個產品、零件、材料的庫存數字(安全庫存、現有庫存量),我發現真的很多企業主管、工廠倉庫管理人員、採購人員大多數針對庫存量的控管都是只有幾個原則,一、庫存量越低現金流動率越高。二、針對常用物品、通用零材料設定安全庫存數字。

LINE_ALBUM_AI產生圖_240211_107LINE_ALBUM_AI產生圖_240211_287

    上述二大原則方向,一定正確無誤,但我會幾乎都會接著直接問客戶,那麼安全庫存您怎麼決定【數字 (QTY)】,我相信大多數都是說經驗法則,訂單銷售量、生產領料過程的用料量、耗損量等考慮因素,不過我幾乎都會根據實際情況、產業特性、企業流程各種因素給予調整建議,這也是很多客戶委託我們量身定做開發最具有價值的一環,絕對不是只有一個軟體使用,我們是整個進行流程討論,在討論過程我們會把相關產業的做法提出來,雙方共同腦力激蕩,因為客戶的流程與瓶頸客戶最知道,但往往發覺跟我們討論完,才發覺有許多創新變革的流程管理可以導入。

    在這篇分享文,我要特別提出一些對於庫存管理的實施做法(針對加工業、代工廠,單純的買賣業就不需要如此做法),在一個比較複雜的生產過程中,每個產品會經過一連串的製程(或稱工序),而庫存量不是只有針對最終完成品(產品)來控管,必須在各個環節都需進行設定控管基準線,在針對各個工序間我們也必須認真看待每一道工序完成後移交到下一個工序之前的轉移、未轉移的數量,也成為半成品,這些在一個好的管理軟體系統,必須有個工序對應的物料編碼(跟產品編碼是有所區隔),而針對工序角度思考的庫存控管,我們在此可以稱為【流動庫存(Flow)】, 其他的庫存控管稱之為【常備庫存(Stock)】,另外再針對這2種性質的庫存觀念又可以再次各自分類為 【計劃庫存】、【調整庫存】、【偶發庫存】。

    這樣解釋或許大家很難懂,我整理一下表格

計劃庫存 調整庫存 偶發庫存
常備庫存 (1)
以生產目標的庫存控制、季節性的庫存量控管、定期維修措施應變等
(3)
所有品項的安全庫存、JIT看板方式中的加工品
(5)
因疏忽導致過度生產的庫存量、或按生產訂單如期製作,但訂單忽然取消,造成的庫存量增加。
流動庫存 (2)
就是所謂的【帳齡庫存】
(4)
在工序之前進行緩衝調整庫存量、運輸過程的庫存量等。
(6)
工序之間生產速度不一致、或者調度部順利,造成某個工序的半成品特別異常。

(1)計劃常備庫存:

       它是一種依據“生產目標”為目的的庫存控制觀念,非常適合用於按照標準量劃分的產品,維持其庫存水平的情況,以及我們常發生的季節性庫存也是屬於這種類型,因為有些產業受到季節性等因素影響,月生產量非常不平均的行業我相信也是非常多,而這些行業的工廠設備普遍來說,都不具備可以在高峰季節(旺季)有相對應的生產能力,所以我們必須在這些行業中,積極主動地在需求量較少的淡季,生產較多的產品進行庫存,來因應旺季的到來。

      在該庫存量的制定方式,主要是根據一整年的宏觀需求預測為基礎來進行,這個軟體系統就必須根據多年來的歷史訂單、或者市場調查進行預測分析。

(2)計劃流動庫存

        存貨帳齡(帳齡庫存)就是典型屬於這一類,這也是產品工程設計中,都必須提前準備的庫存量。

(3)調整常備庫存

        這就是我們一直常聽到的JIT看板方式中的加工數量控制、或者大家最知道的【安全庫存量】設定,它是一種用於應對需求方的緊急變動,或為吸收生產作業線因為供應方問題導致供應數量的瓶頸,主動安全防範的庫存量。

(4)調整流動庫存

      這類型就是在工序與工序間,在加工製造過程中用於緩衝調整加工品的數量、或者運輸過程中的庫存量,都歸於這個類型。

     以及我要而外一提,常常因為原物料供應商和工廠製造商因為在“批量”的不一致,例如生產時採用件數為單位,而供應商發貨包裝是採用貨板單位,在這種狀況下,產品到了裝滿1貨板就需要臨時保管;相反來看就是,購買原物料時採用貨板單位,而供應商發貨是採用件數單位,這樣同樣都需要等到填補批量差異的調整庫存。

(5)偶發常備庫存

       就是因疏忽導致過度生產的庫存量、或按生產訂單如期製作,但訂單忽然取消,造成的庫存量增加。

(6)偶發流動庫存

     工序之間生產速度不一致、或者調度部順利,造成某個工序的半成品特別異常。

     也因為調度的不順暢、先前作業完成之後,需要接續的工序作業無法繼續進行生產,也是屬於這類性庫存定義。

而我特別整理上述這些庫存管理的範疇,在好的一個軟體管理系統(ERP、MRP、進銷存、POS系統、MES等),都應該在某個功能進行輔助,例如(1)計劃常備庫存和 (3)調整常備庫存,就是常看到的設定品項安全庫存量、根據訂單跑出生產計劃需求量,這個我建議可以參考我其他寫的文章,當然如果您有任何問題,也跟歡迎聯繫我們,任何問題我們都可以提出一些看法,也針對客戶產業流程特性進行專業的系統分析。

(其他參考文章)

MPS主生產計畫專文介紹(一)

MRPⅡ/ERP 能力需求計畫原理

庫存管理-概念與釐清

庫存管理探討-VMI

真正的庫存量形成探討

庫存管理的中樞控管法則(上)

庫存管理的中樞控管法則(下)

BOM表管理與設定﹣輔料是否需輸入BOM

何謂 進銷存、ERP、WMS?三者差異性【軟體開發、軟件開發、程式設計】

ERP 產品成本管理與計算

網智數位-軟體開發(軟件開發)
針對各特殊產業都可以量身定做符合貴公司的需求,別人無法克服的就是我們的挑戰
業務合作、軟體委外開發
業務窗口:allen@netqna.com
聯繫電話:0920-883-870
skype: netqna
line:netqna
微信:netqna
黃先生 Allen