注：臨近過年假期，準備在假期階段不再寫新的技術類文章，而是對自己15年來的博客文章按年為單位做下總結(jié)和整理。按新浪博客當前記錄是4229篇博客文章，其中3000篇以上的個人原創(chuàng)文章，接近4年的博客日更寫作。
你的燈亮著嗎？
對于專談問題的書，2006年閱讀了《你的燈亮著嗎？》，這本書是著名思想家溫伯格（其著作還有系統(tǒng)思維導論，程序員開發(fā)心理學）的一本定義分析和解決問題的書籍。全書分六篇由20個寓意深刻的小故事組成，講述層次仍然遵循定義描述問題－》分析問題－》解決問題的思路，故事中穿插了諸多的最佳實踐和案例供大家參考。
讀一本書就能夠?qū)W會如何解決問題是不可能的，所以該書也不是按部就班地教你如何解決問題，更多的我覺得應該是大家通過閱讀該書有所思，有所悟，最終形成自己的分析和解決問題的方法論。
比如在這篇里面給出的對問題的定義，即問題是你期望和和你體驗間的差別，要分析和解決問題時候首先需要搞清楚什么是真正的問題，問題從哪里來是誰的問題等內(nèi)容。在工作和生活中常犯的毛病是扭曲問題定義，自己人為地去解釋和翻譯問題從而導致把問題的解決方法作為問題的定義。 從而導致后續(xù)一連串的錯誤。
對于分析和思考問題，則是需要搞清楚問題的來源，是誰的問題，導致問題的真正根源是什么，原來是否遇到過類似問題等內(nèi)容。分析和思考問題是否全面直接影響到后續(xù)問題的解決。本書給出的幾個重要Tips是：
A.如果你找不出三處可能出錯的地方，說明你沒有真正理解問題
B.不要輕易給問題下結(jié)論，也不要忽略你的第一印象
解決問題是最后一步，建立在分析問題基礎上，解決問題有多條途徑，如果通過各種約束條件選擇最佳的途徑來解決問題是需要考慮的重要因素。比如書里面提的當別人能夠解決問題的時候千萬不要越俎代庖，而應該引導他人思考和自己解決；再比如一個一個小小的提醒往往比復雜的解決問題方法更有效，也就是這本書的書名，車出隧道后提醒司機關閉車燈應該如何提示才最簡潔有效。
高效能人士的7個習慣
我個人寫過很多的關于個人知識管理，自我管理，自律，個人計劃和行動等方面的文章。但是你會發(fā)現(xiàn)很多內(nèi)容都能夠在這本書里面找到影子。也就是說這本書里面的7個習慣是可以伴隨一個人終身進行自我學習，持續(xù)改進和實踐的，單單一個積極主動要做好都很難。
雖然在06年就在讀這本書，但是感覺在最近2到3年很多內(nèi)容才真正實踐到位，通過實踐去理解里面的內(nèi)容，比如以終結(jié)為識的深刻道理。
這本書給我的幾個關鍵啟發(fā)點，簡單來講即：
其一你要形成個人做事情的原則，比如公正，誠信，守時，尊重他人，履行諾言都是應該遵守的原則。這個原則要長期堅持，不要因為你面對的外在環(huán)境或人輕易改變，真正做到表里如一，做到慎獨。
其二是關注圈和影響圈，你的目標是擴大自己的影響圈縮小自己的關注圈。多去影響他人而不是經(jīng)常被他人影響。你是主動的去工作和生活，而不是被動的去接受。
其三就是發(fā)展的三個階段，獨立期只是中間階段，更加重要的是互賴期的合作共贏，這個需要走出去，打破自我邊界，以一種開放的心態(tài)面對外在。
IT人員的知識體系架構
這個是我在2006年整理的IT人員的個人知識體系結(jié)構，在這個之后又相繼整理了IT咨詢?nèi)藛T，需求人員，手游賬號出售項目管理人員的知識體系結(jié)構。
為何整體這個？
簡單來說即當你在一個業(yè)務領域或崗位呆太久后你會發(fā)現(xiàn)沒有啥新東西可以學習，陷入一種重復機械式的工作階段而無法自我提升，而整理知識結(jié)構的重點就是真正看清楚整個知識體系完整框架，并清楚你當前的位置在哪里。
如果你不知道去哪里，給你一張地圖也沒有用。
知識體系結(jié)構比較好的地方就是可以結(jié)合當前自己的知識技能，個人的成長期望和目標來制定進一步的學習路線，持續(xù)改進。
像青蛙一樣思考
首先不應該簡單地把該書歸類為厚黑學類的書籍，更多的是教會我們認清國內(nèi)企業(yè)文化，在企業(yè)特有潛規(guī)則下學會做人和做事情。
全書一開始就列舉出了企業(yè)內(nèi)部常見的十大泥潭，使我們經(jīng)常絞盡腦汁的面臨兩難抉擇，每個人都希望自己擁有敏銳的思維解決和避開以上現(xiàn)象。個人的智商是認清企業(yè)的顯性規(guī)則；而個人的情商確實幫助我們發(fā)現(xiàn)和解析企業(yè)的潛規(guī)則，而更好地去利用這些潛規(guī)則。
小恐龍的迷惑：剛踏出象牙塔走上工作崗位的所有畢業(yè)生，都是滿腹經(jīng)綸，滿懷抱負，自認為自己有先進的理論武裝自己，才高八斗，希望在工作中一展鴻圖，一到公司后敢說敢做，腦子里面有說不完的新想法和新思路，但卻不能被人重視和采納。自己也在多次受挫后喪失了對工作的興趣和熱情。在恰當?shù)臅r候說恰當?shù)脑挘稣_的事情而不是正確的做事，這些可能更是我們該學習的。
模仿永遠只是外在的，核心的精神是無法模仿的。 企業(yè)文化不是無源之水，無根之木，它根植于現(xiàn)實的土壤，并受現(xiàn)實的力量所左右。在一杯臟水中不可能倒出一杯清水，只有學會了在泥潭中生存，才能夠真正突破泥潭的桎梏。
先進的管理學思想得以長驅(qū)直入，而在運作層面卻遭遇到軟性的抵抗，這與我們的泥潭文化有著重要的關系。就如同ERP,CRM在企業(yè)實施中遭遇到的空氣阻力，本來提高效率的管理工具卻轉(zhuǎn)變?yōu)榱似髽I(yè)的形象工程。
崇尚權利，否定個體，缺乏誠信，貪功和拉幫結(jié)派是泥潭文化中典型的負面因素。我們經(jīng)常被這些負面因素困擾而不快樂，存在即合理，因此不應該去逃避這些負面因素，而是如何去應對這些負面因素，又能夠不違背自己的準則和價值觀。
功能點估算-原理和案例
在06年的5月我整理了功能點估算原理和案例的兩篇文章。對于功能點估算當時詳細說明估算原理和過程的文章很少，因此這兩篇文章后面閱讀量都比較大。
Function Point Estimation 功能點估算是一種用來估算項目大小的技術。功能點是對軟件功能和規(guī)模的間接定量測量，它基于客觀的外部應用接口和主觀的內(nèi)部應用復雜度以及總體的性能特征。
功能點法和專家法估算最大的不同點在于對估算規(guī)模的細化的定量分析上面．我們在用專家法估算的時候往往會直接去估算工作量，或在規(guī)模的估算中摻雜了生產(chǎn)率的數(shù)據(jù)，導致估算數(shù)據(jù)出現(xiàn)問題．專家法估算雖然有時候也很準確，但不能提升為組織級可以參考和借鑒的同樣規(guī)則．其實專家法的估算要做準確也是遵循了功能點法估算的思路，在考慮一個軟件功能究竟涉及到哪些操作，涉及到多少數(shù)據(jù)文件的存在，每個操作需要訪問哪些數(shù)據(jù)文件等相關問題．只是這些想法停留在專家頭腦里面而沒有量化出來。
功能點法進行估算的時候具體過程是：
1.對估算功能單元的類型進行識別
2.計算每種類型的復雜度．
3.計算總體的調(diào)整前的功能點數(shù)
4.根據(jù)調(diào)整因子對功能點數(shù)進行調(diào)整
當前真正應用功能點估算的很少，而實際在我們后續(xù)的項目基本也是基于功能點估算的思路進行了改進，形成用例點估算方法并使用。
什么是模式？
簡單來說，模式就是經(jīng)過無數(shù)次的實踐和失敗總結(jié)出來的，解決特定場景下的特定問題的解決方案和最佳實踐。
對于模式，Pattern Alexander給出了經(jīng)典定義：
每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題,然后描述了該問題的解決方案的核心，通過這種方式 你可以無數(shù)次地使用那些已有的解決方案 無需再重復相同的工作。模式作為現(xiàn)實世界中的一個元素，都是以下這三者之間的關系，它們是：特定的情景，在該情景下反復出現(xiàn)的特定壓力系統(tǒng)和使這些壓力能夠自我釋放的空間配置。
作為語言的一個元素，模式是一條指令，說明了如何重復地使用這個空間配置，一旦給定的情景適當就釋放給定的壓力系統(tǒng)。簡而言之，模式是一種出現(xiàn)在現(xiàn)實世界的事物，同時它也是一條告訴我們?nèi)绾蝿?chuàng)建，何時創(chuàng)建該事物的規(guī)則。它既是一個過程， 又是一種事物；既是對一個存在的事物的描述 又是對生成該事物過程的描述。
因此每個模式一定要包括問題，場景，壓力和解決方案四個要素。
問題：你遇到了什么難以解決的問題？
場景：你是在那種場景下遇到的問題，不同場景下遇到相同的問題也可能采取不同模式。
壓力：有哪些影響方面，哪些約束，由于問題復雜性需要如何折中處理？
解決：在以上三要素約束和作用下，已經(jīng)被前人實踐證明的可行方案。
開發(fā)人員效率差在哪里？
如果你讀過類似《軟件工藝》或《人件》這類書籍，里面經(jīng)常會談到好的開發(fā)人員的開發(fā)效率往往是一般人員的10倍甚至更高。
那么開發(fā)人員效率究竟會差在哪些地方？在2006年的時候自己進行了總結(jié)如下：
熟練人員經(jīng)過多年的積累加上自己的CodeSnip的總結(jié)，基本不用額外再查找資料。而一般的開發(fā)人員在開發(fā)過程中會花掉10-20%時間去查找資料。
熟練人員注意代碼復用，并且時刻注意重構和抽取公用代碼。一般開發(fā)人員是代碼拷來拷去完成功能。
熟練人員非常注意查找，定位，標簽等各種快捷鍵的使用，定位查找方便快捷，IDE環(huán)境也根據(jù)習慣定義到最方便狀態(tài)。
熟練人員編碼前先思考清楚整個流程，在頭腦或紙張上規(guī)劃好整個實現(xiàn)方式和方法函數(shù)的劃分。一般人員想到哪里寫到哪里。
熟練人員寫了50行以上或更多代碼才Debug一兩次，一般人員寫了幾行代碼就要Debug多次，完全通過Debug來驗證代碼正確性。
熟練人員注重代碼的質(zhì)量，單元測試和可維護性，注重各種業(yè)務邏輯的驗證和邊界條件的校驗。一般人員只注重簡單功能的簡單完成。
熟練人員提交測試的代碼BUG很少，返工工作量很小。一般開發(fā)人員由于自測不完善BUG較多，造成大量的返工工作量。
熟練人員合理分配自己的時間，規(guī)劃好每天工作任務，開發(fā)過程各位專注。一般開發(fā)人員一心多用，邊開發(fā)邊聊Q。
熟練人員善于知識的總結(jié)和積累，形成自我的知識庫和經(jīng)驗庫。
熟練人員善于發(fā)現(xiàn)問題，分析不足而自我持續(xù)改進。一般人員在外力干預俠被動改進。
熟練開發(fā)人員開發(fā)重點已經(jīng)專業(yè)到對業(yè)務的深刻理解，一般開發(fā)人員考慮的是開發(fā)上編程的語言和工具。
熟練人員善于從各種影響自己開發(fā)效率的因素中擠時間，善于使用各種輔助開發(fā)工具。而一般人員則不善于這種總結(jié)。
方法論的切入點
方法論是可以解決特定場景下的問題的一系列方法，過程，工具，技術的集合。而學習方法論往往更應該從小問題出發(fā)，學習相關步驟和其系統(tǒng)思維的方式。
然而對于小問題我們往往一眼就看到了答案，而忽略按部就班地去使用方法論，去積極地鍛煉自己的思維過程，或者是先想到了答案再根據(jù)結(jié)果再反推著具體的步驟和方法。這樣導致我們遇到復雜的問題時候往往感到無從下手，因為這個時候缺乏的已經(jīng)不是步驟的問題，更多的是缺乏系統(tǒng)的思維模式和實踐。
我當時舉了一個例子如下：
當爬一個小山坡的時候，還沒有爬可能就看到了頂點，看到了中間的亭子等重要里程碑，所以爬的時候也不會去考慮什么方法，也不用去思考也能夠正確的爬到頂點。而當你爬一座高山的時候，頂點遙不可及，或者連中途的里程碑點都無法看到，所以這個時候你爬的時候心里面沒有底，也不知道自己是否偏離路線，也不知道按現(xiàn)在方式能否成功爬到山頂。
可能到這個時候你才會真正意識到了自己在爬小山坡的時候沒有注重這些步驟和技術的練習，所以你始終處于爬山的初級階段。
當平時遇到簡單問題解決起來得心應手，而一遇到復雜問題就感到無所適從的時候是否該反省和總結(jié)下相關的方法論。當對于簡單的系統(tǒng)或功能設計和開發(fā)起來游刃有余，而遇到復雜的系統(tǒng)卻無法進行分析和設計的時候，是否該考慮下系統(tǒng)化進行分析和設計的思維方式和邏輯。
如何循序漸進向架構師發(fā)展
自己原來做DotNet開發(fā)，當時寫過一篇文章，即如何循序漸進地向DotNet架構師發(fā)展?，F(xiàn)在摘錄了里面部分內(nèi)容。
設計和編碼其實是密切而不可分的，對于嚴格將設計和編碼分開的瀑布模型一般也僅僅在大型項目中應用。而及時編碼和設計分離，也不是將編碼人員不需要思考，編碼活動始終是一項創(chuàng)造性的勞動，如果否定這個觀點那就代表編碼過程完全不需要人員介入而可以完全自動化。
因此在這里談設計主要還是指設計人員的系統(tǒng)化思維能力，設計人員應該比開發(fā)人員站高一個層次來分析和思考問題。設計人員最重要的一個技能就是現(xiàn)實->抽象的轉(zhuǎn)換，而這個就需要談到方法論的問題了，技術人員需要積累面對對象分析和設計或結(jié)構化分析知識的積累，需要有較強的數(shù)據(jù)庫分析和設計能力。一個設計人員能否成為很好的架構師關鍵就在這種積累的深度和廣度上面了。
因此在設計過程中應該考慮的問題有：
你現(xiàn)在分析和設計能力能否勝任大中型的應用系統(tǒng)還是只是獨立功能分析和設計？
設計過程中是否有意識的考慮到組件的復用和相關接口設計準則。是否能夠很自然的將分析模式，設計模式的相關內(nèi)容應用到自己的設計過程中。
是否對XP，RUP，面向?qū)ο?，結(jié)構化等方法論都有過較系統(tǒng)化的學習和思考。
是否真正理解系統(tǒng)功能需求和非功能需求對系統(tǒng)設計的不同的指導作用。
對自己設計的功能是否會根據(jù)后期的變更來反思自己的設計為何不能很好的適應變更？
是否在設計過程中經(jīng)常自己開發(fā)些原型來對自己的設計思路進行驗證？
是否專注技術的同時開始專業(yè)業(yè)務流程的分析，關注業(yè)務建模？
如果我們在設計和開發(fā)過程中經(jīng)常關注這些知識和技能的話，成為一個合格的架構師是早晚的事情。平時能夠勝任工作開發(fā)用到的知識和技能是微不足道的，如果自己不是有意識的去學習這些知識的話，那技能是很難得到進一步提高的。
讀書只有兩個層次
對于知識來講分為兩類，有鍛煉智商類的知識，也有鍛煉情商類的知識。而我們讀書的兩個層次正好和這兩類知識相對應。
鍛煉智商的知識，就如常說的工程技術，理工方面的知識。這類知識的理論和技術性都很強，因此一般遵循的學習路線都是：理論->實踐->理論->實踐；這類知識如果沒有基本的理論儲備而想在實踐中去尋找真理是很困難的，所以這類技術知識我們一般都是站在巨人的肩膀上，在前人已經(jīng)獲得的理論指導下，先進行相關理論的學習，再實踐，再完善自己的理論。鍛煉情商的知識，如現(xiàn)在的管理類，思維類，溝通方面，成功學等方面的知識。這類知識更多的是依賴個人的情商而非智商，因此應該遵循的學習路線是:實踐->理論化->指導實踐->理論積累的方法。
任何企圖通過成功學書籍或理論來指導成功的都將是徒勞。因此特別是這類書籍，如果沒有相關的生活感受，工作經(jīng)歷，即使讀了也很難有很大的收獲。更多的應該是有了實踐經(jīng)驗的積累，有了失敗的教訓再或過頭來讀這些書，進行自我的反省和總結(jié)，把相關的經(jīng)驗理論化下來后指導后續(xù)新的實踐。
知識存儲和思維有感
人的大腦的容量是有限的，那大腦究竟應該存儲哪些知識以及如何存儲？
首先一部分是存儲理論知識，另外一部分是用來存儲理論知識經(jīng)過實踐后或者說沒有通過理論完全通過自我實踐得出來的經(jīng)驗和技能。
實踐最重要的還是要形成解決問題的方法論或模式，所以這里有三個要素就是場景，問題和解決方法。這也應該是構成我們經(jīng)驗的重要要素。
我們存儲的理論知識如果經(jīng)常不使用或不實踐也會遺忘掉，就如你現(xiàn)在根本無法再記清楚高中的幾何學公式一樣。因此出了學校進入了工作階段后原來存儲理論知識部分要全部移出來存儲經(jīng)驗＆技能。只有經(jīng)驗和技能才具備了更長久或永久的記憶可能。
我們一直在做的事情就是要解決特定的問題時候，再來回顧需要用到的理論知識，通過應用理論解決了實踐問題后將其轉(zhuǎn)化為經(jīng)驗再進行存儲。這樣才可能最大限度利用大腦的存儲容量。
所以在進入了工作階段后我不提倡任何強化記憶的方法，任何沒有實踐或理解的記憶都將是暫時的。
當工作積累或經(jīng)驗越來越多的時候，會發(fā)現(xiàn)大腦僅僅用來存儲經(jīng)驗教訓或相關技能也不夠了，所以這里應該只記錄場景+問題+方法即可，而對于具體的解決步驟，技術或工具應該僅僅記錄索引。只要我們在應用的時候能夠方便找到就可以了。
大腦的容量是有限的，所以我們一定不能去存儲沒有分解的粗粒度的問題域，而應該將其分解和提煉，并且要重新整合。只記錄細粒度的模式條目，這種可以簡短到一句話歸納的模式語言是最重要的經(jīng)驗和技能庫。
關于人員流動的動態(tài)建模分析
系統(tǒng)思維始終和動態(tài)過程是聯(lián)系在一起的。系統(tǒng)動態(tài)學從整體的角度來看待事務，考慮系統(tǒng)中各個對象和因子間的相互影響和作用。當系統(tǒng)中各個因子間的相互作用力達到一致的時候，系統(tǒng)處于一種動態(tài)平衡的狀態(tài)，當任何一個因子由于外界環(huán)境因素影響而改變都會打破這種平衡，動態(tài)的系統(tǒng)在這種平衡被打破后由會去不斷的去調(diào)整各因子的值和相互作用，直到下一次動態(tài)平衡。
I Think,I see。
對于基于這種思想的動態(tài)思維建模和模擬軟件iThink能夠為我們很好的將我們頭腦里的想法用模型記錄下來。我們相信直覺，直覺也經(jīng)常幫助我們做出準確的判斷，但對于多于復雜的多因素影響的系統(tǒng)直覺則往往是錯誤的。即使直覺正確也經(jīng)常只能夠告訴我們是或否，但具體的數(shù)量級的概率或精確點的數(shù)據(jù)則是無法得到的。
經(jīng)驗或直覺在沒有通過模型固化下來之前是沒有很好的傳遞性和繼承性的，只有通過模型將思維固化下來才能夠形成相關的理論或方法。
對于軟件團隊中人員流動問題在《最后期限》一書中也專門進行了模型的模擬。在這里將根據(jù)自己的思路對該模型重新進行整理和建模。
首先我們需要得到一個在人員不流動，其項目團隊成員都是熟練員工的情況下的一個平衡模型。在這個平衡模型下堆積100個功能點的需求，每天流入新需求約5個功能點，項目團隊成員 10人，每周工作40h，每小時的生產(chǎn)率為0.0125FPS/h，在這種情況下項目以迭代方式進行多版本發(fā)布，每個版本持續(xù)時間為8周，因此新提交的需求一般在2個月后就可以上線運行。在這種情況下我們得到一個平衡的模型，在這個模型模擬Running的過程中，堆積需求始終保持在100FPS.
對于每周40h是理想的情況，當需求積累過多而無法滿足的時候往往需要員工加班來解決問題。我們?nèi)蝿占影?0h是每周加班的極限時間，而具體的加班時間跟需求積累比率成正比。如果累積需求達到了200FPS,即比率為2時候，則需要加班到80h左右。因此可以利用iThink的圖形建模功能得到一個加班時間與需求累積率的函數(shù)。
假設人員流失為每季度即12周流失一名成員，對于項目成員流失的時候一般提前4周進行資源的提前補充。因此對于人員流入和人員流出都為階段點的非連續(xù)性數(shù)據(jù)。在老員工離職后新員工的技能提升是一個長期的過程，新員工要達到老員工的生產(chǎn)率水平一般需要2年的時間，但經(jīng)過1年的時間基本可以達到7成水平，在這里新員工的技能水平提升符合學習曲線。
為了模擬較長的單位，將最小時間修改為1個月，同時對新員工的學習曲線修改為線性的方式。對于新員工增加后，需要占有老員工的培訓時間，這里暫時將項目可用人數(shù)減少0.5進行處理。新員工剛進入時候的技能水平為0.4,以后每一個月后增加0.025,則兩年后達到熟練員工的水平。由于需求積累超過限度后引起的加班，暫時不考慮加班過長對人員效率人員流水的影響。對于員工離職，模型假設新員工可以提前一個月入職接手相關工作。
在這種情況下進行模擬后發(fā)現(xiàn)最終的生產(chǎn)率水平保持在原有生產(chǎn)率的70-80%左右，而且由于生產(chǎn)率下降引起的需求積累，導致加班增加，加班曲線呈現(xiàn)持續(xù)增長狀態(tài)，顯然這并不是一個能夠平衡的動態(tài)模型。為了減少加班情況，在第一年末在模型中新投入一名不需要培訓的熟練員工。加班曲線可以降低下來到46h左右。
需求也不再持續(xù)累積增加而穩(wěn)定到120-130的水平。
供應鏈頂層數(shù)據(jù)流
這篇文章寫在06年的年末，當時對供應鏈管理，采購和庫存控制策略，MPS主生產(chǎn)計劃和MRP物料需求計劃，研發(fā)管理和BOM等業(yè)務知識進行系統(tǒng)的學習和整理。
當前印象里面是參加了i2組織的封閉1個月的APS相關知識培訓，相當系統(tǒng)，這些業(yè)務和IT知識融合進一步完善了個人業(yè)務領域的知識結(jié)構。
這篇文章當時筆記記錄如下：
1.訂單要用來沖減預測，訂單要考慮訂單本身優(yōu)先級，再考慮時間優(yōu)先級．都經(jīng)過排序后按照排序的先后關系進行沖減，入MPS的數(shù)據(jù)流為確認后的訂單信息和沖減后的凈預測信息．
2.除了訂單和預測外．MPS的輸入還有確認后的已經(jīng)下達的請購申請， 在制．成品和半成品的庫存．對于ATO裝配型企業(yè)MPS一般要做到半成品層，這時候MPS需要考慮計劃BOM分解．對于其它一般考慮分解到產(chǎn)品層，得到產(chǎn)品分時段需求和計劃下達量信息．
3.MPS和MRP不直接交互信息,MPS主計劃的結(jié)果僅驗證主計劃和能力的可行性．這里需要人工干預，即在主計劃驗證可行后具體的需求請購信息仍然人工下達，需求請購既用于主計劃的MPS的扣減，也用于MRP的入口信息．
4.MRP的分解原則分兩步進行，首先第一步全部分解到最底層的原材料級別的需求，這里源頭是需求請購，除了要考慮庫存和加工周期外，還要考慮執(zhí)行中的WIP和在途的采購訂單．第一步完成后再考慮原材料這塊的采購提前期和庫存約束，供應商和物料約束．當我們需要考慮產(chǎn)能的時候也應該是首先運行無限產(chǎn)能計劃，再考慮產(chǎn)能約束計劃．
5.為了更好地進行供應鏈協(xié)同，往往跟供應商間還需要及時地交換和共享預測信息，MRP信息和庫存信息．供應商反饋的庫存信息會額外增加為運行供應鏈計劃的約束條件．只有真正實現(xiàn)了這種信息的及時協(xié)同，才可能最大化的壓縮采購周期和降低庫存．
6.幾個沒有想得很清楚的問題．如果要考慮需求計劃和采購訂單的一一對應關系，則要增加相關的資源鎖定功能，跑增量MRP還好辦，如果是跑全量的MRP則還需要考慮歷史對應關系信息，非常麻煩。
聯(lián)系客服
