sap工程項目管理案例

❶ SAP的中國客戶有沒有在建築工程行業應用案例！

SAP有專門的EC&O（設計、建造、運營）行業方案，針對建築和房地產行業有專門的方案的。我一直在研究這方面。你們是商業地產？還是普通的住宅？希望有機會能夠合作

❷ SAP的失敗案例有哪些

想推薦公司上SMB的系統，價格方面是老闆考慮的因素之一。SAP的不成功項目也是老闆擔心的一個原因。誰能提供些SAP不成功案例的例子？由於話題比較敏感，煩請PM給我，或MSN中聊。我想分析一下，除了顧問、公司內部管理因素以外的原因－－最好有深圳、廣東的案例。

❸ 急需軟體項目管理案例，要案例就行，軟體項目的~

A公司是一家美資軟體公司在華辦事機構，其主要的目標是開拓中國市場、服務中國客戶，做一些本地化和客戶化的工作。它的主要軟體產品是由總部在矽谷的軟體開發基地完成，然後由世界各地的分公司或辦事機構進行客戶化定製、二次開發和系統維護。這些工作除了日常銷售和系統核心維護之外，都是外包給本地的軟體公司來做。東方公司是A公司在中國的合作夥伴，主要負責軟體的本地化和測試工作。
Bob先生是A公司中國地區的負責人，Henry則是剛剛加入A公司的負責此外包項目的項目經理。東方公司是由William負責開發和管理工作，William本身是技術人員，並沒有項目管理的經驗。
當Henry接手這項工作後，發現東方公司的項目開發成本非常高，每人每天130美金，但客戶的滿意度較差，並且每次開發進度都要拖後，交付使用的版本也不盡如人意。而且，東方公司和A公司矽谷開發總部缺乏必要的溝通 只能把問題反饋給Henry，由Henry再反饋給總部。但由於Henry本身並不熟悉這個軟體的開發工作，也造成了很多不必要的麻煩。
為此，Bob希望Henry和William用項目管理的方法對該項目進行管理和改進。隨後，Henry和William召開了一系列的會議 提出了新的做法。
首先，他們制定了詳細的項目計劃和進度計劃;其次，成立了單獨的測試小組，將軟體的開發和測試分開;並且，在矽谷和東方公司之間建立了一個新的溝通渠道，一些軟體問題可以與總部直接溝通;同時，還採用了里程碑管理。
六個月後，軟體交付使用。但是客戶對這個版本還是不滿意，認為還有很多問題。為什麼運用了項目管理的方法，這個項目還是沒有得到改善?
Henry和William又進行了反復探討，發現主要有三個方面問題：1、軟體本地化產生的問題並不多，但A公司提供的底層軟體本身存在一些問題;2、軟體的界面也存在一些問題，這是由於測試的項目不夠詳細引起的;3、開發的周期還是太短，沒有時間完成一些項目的調試，所以新版本還是有許多的問題。
此時，Henry向Bob提出是否採用公開招標的方式，選擇新的、實力更強的合作夥伴。但Bob認為，與東方公司合作時間已經很長了，如果選擇新的夥伴又需要較長的適應期，而且成本可能會更高。於是，Henry向東方公司提出一些新的管理建議。首先，他們採用大量的歷史數據進行分析，制定出更詳細的進度計劃;其次，要求東方公司提供詳細的開發文檔和測試文檔 做的工作沒有任何文檔，給其他工作帶來了很多困難);第三，重新審核開發周期，對里程碑進行細化。
又過了六個月，新的版本完成了。這一次，客戶對它的評價比前兩個版本高得多，基本上達到項目運行的要求。但客戶還是對項目進度提出了疑問，認為實時推出換代產品不需要那麼長的時間。
較常見的做法。在軟體外包工程中，保證質量的進度是很難控制的。對於項目經理來說需要一整套復雜的能力，比如制定計劃、確定優先順序、干係人的溝通、評價等，每一種能力都與項目的最終結果有直接或者間接的關系。
然而，國內的項目經理大多沒有接受過正規訓練，缺乏項目管理方面的專業知識的技巧，往往只是憑藉以前的少量經驗盲目去做，容易出現各種問題。尤其是在管理外包項目時，缺乏足夠的經驗和技巧，往往造成進度不斷推遲，而質量無法保證的情況。
在這個案例中，我們可以看到現在IT業內許多外包項目的影子。
在該案例中，東方公司沒有專門的項目經理，是由技術人員William兼做管理。這是國內軟體公司經常會出現的問題。最初，出現進度落後的問題時，A公司的Henry與東方公司的William討論後決定採用項目管理中計劃管理等手段，其中包括里程碑管理。這是控制進度的較常見做法。
里程碑管理的引入
一般來說，在項目開始時，項目組成員都會對項目制定一個詳細的計劃。通常情況下，在明確的工作說明書(SOW)和WBS的基礎上制定具體的進度計劃時，需要採用一些具體的技術。像這種軟體外包項目，最成熟的技術是里程碑管理。
里程碑一般是項目中完成階段性工作的標志。不同類型的項目，里程碑也不同。比如，在開發項目中，可以將需求的最終確認、產品移交等關鍵任務作為項目的里程碑。本案例中，Henry在接手項目後採用里程碑進行管理是很恰當的。
不過，要注意的是，每到一個里程碑處，應及時對前段工作進行小結，並對後續工作進行計劃調整。對於一些管理效果明顯的領域，可以不必投入較多精力。而對於下一步管理過程中可能會出現問題的領域，應給予較多的關注。當然，在軟體項目里，進度的變化是較常見的事情。
在本案例中，採用里程碑管理後仍沒有達到客戶的要求，進度依然拖後。在這里，就需要考慮另一個因素-質量與進度的關系。
通常，項目管理的前提是保證在預算內、滿足質量的前提下，按進度完成項目。因此，可以看到，保證質量是前提。那麼，如何在滿足質量的前提下管理進度呢?單純從項目管理理論知識中並沒有一種有效的方式。具體步驟為：
首先，盡量利用歷史數據。在本案例中，Henry應該調查之前的項目情況，將會發現可以類比的情況，事先就可以知道需要管理質量和進度的關系。
其次，由於此項目是軟體外包項目，Henry不能完全掌握項目的資源 調度情況，因此缺乏對質量的控制。這也是大多數外包工程中最令人難以掌握的地方。在這里，可以採用對進度管理 <http://www.csai.cn/incsearch/search.asp?key=%BD%F8%B6%C8%B9%DC%C0%ED>計劃添加質量參數的方法，也就是通過參數調整進度和質量的關系。
這一做法的前提是要有一定的歷史數據。比如，從歷史數據中得知，完成子項目的時間是5天，測試後有15個問題;完成同樣子項目的時間是7天，測試後有10個問題;完成同樣子項目的時間是8天，測試後有5個問題，……以此類推。
隨著數據的不斷增多的，採用兩維坐標圖，就會得到一些離散的點(不考慮資源的差異)，並形成一條曲線，見圖1。考慮項目允許的質量范圍，對照圖中的數據，找出相應的參數。根據得到的參數，確定一個合適的進度計劃

❹ 求SAP公司的關於工程項目管理系統的功能模塊的文檔

隨著電力市場改革的深入競爭壓力日益增大，電力企業原有的管理體制面臨改革。迫使企業需要堅持以科技為先導，依靠科技進步、技術改造實現節能降耗和增效。因此，為了及時建立以經濟效益為中心的經營管理新機制，浙江省電力公司於1998年和1999年先後在其下屬主要電廠及電力局實施國外成熟的SAP R/3軟體的FI/CO（財務成本）模塊和PM（工廠維護）/MM（物料管理）模塊。 紹興電力局作為浙江省電力公司的一個下屬電力局，作為試點率先在成功實施了SAP R/3軟體的FI/CO（財務成本）模塊之後，於2000年6月開始實施PM（工廠維護模塊）和MM（物料管理模塊），已於2001年初上線，並與之前已實施的FI/CO（財務成本）模塊有機地集成。通過PM/MM的實施，紹興電力局將實現設備維修、物資的集中管理。 二、項目需求 1. 高級管理層 隨著電力改革的日益深入，電力企業面臨提高內部管理水平的巨大壓力。目前，財務、維修、物料等工作已通過ERP軟體進行管理，基礎建設、技術改造是資金佔用相對較大、管理較困難的項目，亟需使用系統工具規范項目管理，藉助現代的管理方式來跟蹤、監控項目從項目計劃、審批、建設、決算的全過程，實現新系統與原有SAP系統各模塊的有效集成，真正豐富項目管理手段和改善項目管理方式。 2. 項目建設部門（基建處） - 亟需使用系統工具規范基建項目管理的工作程序； - 相關部門與其工作程序中的對應關系的明確，保證各司其職，避免發生由於工作關系不明確導致項目進度受到影響； - 由於項目管理是一個嚴謹有序，時效性強的過程，所以需要在項目管理過程中設置必要的監控點，對於某些關鍵步驟或關鍵環節應能夠按照一定要求進行預警； - 有效地監控項目中外包子項目的費用發生及項目進度； - 目前在實際工作中，經常出現工程決算滯後，且周期長，由此產生不必要的管理費用及增加費用核算出錯的可能性，不利於公司管理的良性發展，迫切需要及時提供客觀准確的信息及報表工具，幫助監控項目的執行狀況 3. 財務管理部門（財務處） - 監控費用發生與其項目概算的一致性； - 從財務角度對項目的外包部分進行必要的監控； - 准確及時地收集項目費用、成本信息，按照要求自動歸集； - 在針對項目的付款處理時，及時獲取項目進展狀況，以保證費用的發生與項目的進展相適應，保證專項資金運用的合理性； - 在項目竣工結算時，能夠利用系統自動按項目匯集其相關成本總額及明細項； - 在項目竣工結算時需要從不同方面對項目的概算和實際發生的情況進行詳細的比較； - 在項目竣工結算時及時提供准確的報表，如項目相關設備清單等 4. ERP論壇歡迎您業務部門（計劃處、物資供應處、生技處等） - 提供模板功能，能夠方便地在項目計劃模板上修改生成新的項目計劃，從而

❺ 用SAP跑MRP有比較成功的案例么 我在做百度問題。

做網路問題是什麼意思? 測試嗎？

我的上一家公司的MRP跑得還算成功, 當然看你的成功標準是指什麼了.
一般來說, MC利用MRP的結果下單/安排生產, 及MRP結果分析物料欠缺或是溢出情況, 直接生成報表匯報高層等, 在我看來, 這樣的使用效果算是很滿意了.

❻ 建設工程項目管理軟體有哪些

甲方建設工程項目管理系統可以選擇iMIS-PM集成項目管理系統，有過實際的案例與大型企業合作過。

❼ 有沒有2012年的有名一點的項目管理方面的案例

案例三： 一個PDM項目，需求調研已經完畢，正處於開發階段。這時客戶提出想把PDM和常用的三維設計軟體PRO/E進行集成，實現兩套軟體的數據交互。根據PM的經驗和技術人員的反饋來看，這個集成的難度相當大。但PM卻一口答應下來，然後向客戶提出需要對方配合的工作：請客戶方找PRO/E公司，以大客戶的身份要求PRO/E提供所需的數據介面。但是進行這種洽談的話，用戶需要提供正版序列號。實際上這家公司所用的PRO/E全是盜版，領導為此猶豫不決。PM更進一步地提出讓他們乾脆采買幾套正版，不過即使是一套正版，價格也在80萬以上。權衡再三，最終客戶還是主動放棄了這個需求。分析： 出現超出開發能力但又符合項目邊界的需求是項目中最讓人頭疼的問題。這種事情一旦解決不好，很容易讓客戶對供應商的水平產生懷疑，雙方合作產生裂痕，進而影響驗收。這個案例中的PM相當懂得隨機應變，他答應客戶去做這個需求其實是張空頭支票。但是通過巧妙的處理方式，最終的結果卻是需求被主動放棄，而且客戶對PM的好感增加。不過採用這樣的辦法是有風險的，只有事先作好調查，心裡有較大把握，才能付諸實施。 案例四： 某企業即將上馬一個ERP項目。由於以前該企業曾經有一次實施ERP失敗的經歷，所以這次的新項目讓企業相關部門感到緊張，誰也不想碰這個攤子，一致主張低調啟動項目。但是供應商的PM卻力主召開一個隆重的啟動大會，在得到企業方主要領導的支持後，又找公司高層出面，請到了對方企業的上級主管到會，還在會上宣讀了以各個業務部門骨幹為成員，某領導為組長的項目實施小組名單。在害怕項目失敗的壓力下，小組的各成員和責任領導戰戰兢兢，盡力配合好實施的每一處工作，還團結一致消除企業內部的雜音，爭取早日驗收早日完事。這個項目果然進行得異常順利，在規定時間內達到了各項功能指標，通過驗收。 分析： 信息系統對於很多企業而言，都不是離開它就幹不了事的東西。所以客戶中出現散漫或者抵觸對待項目的情況比比皆是。這個時候最好的辦法就是把客戶跟自己捆在一條船上。在這個案例中PM很強勢，他首先說服了對方領導調配各個主要骨幹來參加項目組，然後又讓對方的上級主管知曉此事來暗地施加壓力。這種情況下的項目干係人，唯一的想法恐怕就是安全過關，能用就行。既然抓住了企業中最能說上話的業務骨幹，又降低了他們的心理期望值。這樣的項目，不驗收都難。 案例五： 某PM主導一個工廠的技術改造項目。天天和項目組成員一起泡在對方的車間里，和對方技術人員面對面交流。經過幾個月的埋頭苦幹，逐步完善了系統，最終達到了可以驗收的地步。這時PM去找對方的總工提出召開驗收會。總工大吃一驚：「你們事情做完了？做到什麼程度了？我怎麼不知道？」於是總工又找來主要的幾個負責人，開會了解情況。雖然系統已經可以滿足對方的需求，但是既然領導專門開會，當屬下的自然要憋出幾個新想法來。再加上總工的個人意見，這個項目又出現了較大的需求變化，進度被迫延遲了。 分析： 做項目切忌「埋頭苦幹」。當PM很需要會做表面工作。日請示月匯報，這樣才能讓領導重視。不管客戶上級主管有沒有時間或者興趣了解項目狀況，該做的日報、周報、月報、階段性報告，一定要按期遞交到領導的案頭，就算對方不看，也混個臉熟。而且做了些什麼事情，都是有記錄可查的。如果領導不清楚情況，哪怕下面的具體辦事人員再認可，對項目也沒有太大的作用。
信息化項目管理案例先，S集團明顯缺乏IT戰略規劃，移動商務項目准備時間達到2年之久，而項目的上馬啟動會議竟然是在項目經理不在場的情況下召開的，由此可見，該項目的整體生命周期是有其隨意性的，反應了S集團IT規劃的缺失。項目啟動會議對於項目是非常重要的，其核心在於對項目經理的授權，明確項目高層次目標和項目可動用資源等。鍾劍經理在項目運作當中多次推遲項目上線時間，數據提交的反反復復、項目經理身體力行進行項目加班加點等細節，從側面反應項目經理對資源的掌控還是不夠的，這也是啟動會議沒有到位的結果之一。    其次，S集團移動商務項目的項目計劃制定不合理。從案例看來，項目上線的日期出現多次調整，分別是8月16日、9月1日、10月9日和10月16日，按照項目結果，顯然項目進度是拖延了，但從根本原因分析看來，S集團移動商務項目總體計劃是非常主觀的，如項目啟動會議定下來的「要求在8月16日30個分公司的各個辦事處上線」目標，顯然是值得推敲的。從項目管理角度看來，沒有看到項目管理計劃及其分計劃（如范圍管理計劃、進度管理計劃、成本管理計劃、人力資源管理計劃、溝通管理計劃、風險管理計劃和采購管理計劃）。作為項目經理面對不可實現目標，雖然提出了項目進度方面的意見，但在鄭總的一番「訓斥」下，「鍾劍沒有再做任何辯解」，這種「委曲求全」以保項目上馬的案例國內比比皆是，實際上反應了項目經理鍾劍本身對項目計劃方面經驗的缺失。作為項目經理是為實現項目目標負責的，既然明知不可行的目標，為何要勉強為之呢？從整個案例看來，項目缺乏一個數據管理計劃，數據管理計劃包括數據在項目周期內是如何被管理的，也包括靜態數據、動態數據的格式、收集要求、職責分工、進度要求、數據質量等方面。筆者實施的SAP ERP同樣面臨著數據的難題，除了總部的基礎數據（大小物料、BOM、供應商主數據、客戶主數據，物料數據因為行業特性，初始化達到上億條記錄，可見工作量的巨大），還有全國600家門店的靜態數據和動態數據，特別是動態數據，涉及到數據的一致性，需要同老管理系統核對比較，困難可想而知。筆者在項目的中期，也就是「系統實現」階段，在SAP後台配置的同時就召開數據整理啟動會議，安排各項工作任務，且採取了有效的策略，如靜態數據提前收集、核對進入系統，動態數據多層次、多崗位的核查等。在整個過程中，值得一提的是IT要發揮主導作用，因為數據處理是一件很細致、很煩瑣、工作量很大的事情。我們採取的措施是IT有效的利用EXCEL等函數功能，進行批量數據的比對，也取得了比較好的效果。在項目運作當中，我們更多的做法是IT的高度參與，難題由IT解，薄弱環節由IT幫扶，混亂操作甚至由IT託管等，這是數據管理方面引申開來的，對於項目的成功值得借鑒。    再次，S集團移動商務項目風險管理做得很不到位。從案例看，項目的進度風險是很大的，項目實施過程也證明了這一點。本身作為高層強制性的規定項目進度要求是項目的風險，這是建立在「假設」基礎上的，假設是項目的風險來源之一，需要在項目運作過程中不斷去分析和跟蹤。9月15日反映的統計報表與日常手工報表發生嚴重不符，實際上也是沒有做好風險識別、風險分析和風險應對措施等方面工作。其原因分析是「上線前銷售渠道分類沒有按照標准統一的嚴格規定執行」，這就是風險啊。    再次，S集團移動商務項目的溝通管理也需要總結。8月11日，數據採集只有一半的辦事處回復了，而且數據不是按照標准要求提供的，反應了溝通的不到位。對於項目不同的工作要有因地制宜的溝通方法和溝通技能，從數據採集角度看，完全可以通過正式的、書面的、模板化的要求終端進行數據收集。當項目出現了兩次進度拖延後，9月22日，高層讓鍾劍就數據整理的困難在全國銷售會議上匯報，間接說明項目經理在溝通管理上及其被動。作為項目經理的鍾劍要建立不同級別的項目會議，如項目例會、項目評審會議、項目進展會議、項目風險分析會議、項目決策會議等等，通過及時、有效的專題會議形式完全可以把項目溝通工作做好。另外一個側面細節值得關注，在確定最後項目上線日期10月16日時，項目總監歐陽雪對許建國、王新水的一段話可以看出，項目的歷史溝通頻次還是不夠的。    然後，項目變更控制缺失。有個細節，10月8日，項目經理鍾劍為了調整項目上線日期，以辭去項目經理作「危險」，可見項目變更管理在S集團移動商務項目還是沒有做到位的。對於變更需求，完全可以按照正式的變更管理流程進行。本案例也反映了項目變更管理委員會等變更決策結構還是沒有在項目中建立。作為項目經理是「集成者」、「綜合者」，需要堅定的信念和項目流程管理經驗。從案例看來，項目經理這方面意識是比較薄弱的。    最後，S集團移動商務項目也存在很多亮點，如項目經理鍾劍的項目收尾工作還是可圈可點的，在項目成功上線兩周內，他總結了近三個月的項目問題，整理了一套更完善的項目實施方案，體現了項目經理的綜合能力，也反映了項目管理重視歷史信息和經驗教訓的特點。又如團隊建設方面，項目經理的最終項目上線日期變更郵件，其中反映的國慶長假的集體加班，也包括個大區的項目人員的表現可圈可點，可見項目整體士氣不錯，項目經理功不可沒！
淺談新疆高等級公路建設中的工程變更管理工程變更是公路工程合同管理的重要內容之一，因為施工過程中的工程變更，將對施工進度和工程造價產生很大的影響，因此應盡量減少工程變更，如果必須進行工程變更，則要嚴格按照國家的規定和合同規定的程序進行。新疆吐一烏一大高等級公路及烏一奎高速公路是按FIDIC條款，採用三級監理管理機構進行合同管理，現就建設中的工程變更管理談談自己的認識。      1. 工程變更的定義及提出      凡對合同文件、設計圖紙（含已批準的施工圖）涉及的各種工程的形式、位置、尺寸、數量、質量及標准進行修改和改變，均稱為工程變更。    工程變更產生的主要原因有其主觀原因和客觀原因。主觀原因，如勘察設計工作粗糙，以致在施工中發現許多招標文件沒有考慮或估算不準確的工程量，因而不得不改變施工項目或增減工程量；客觀原因，如發生不可預見的事故，自然或社會原因引起的停工或工期拖延等，至使工程變更不可避免。     工程變更的提出形式有：業主對原設計進行變更；設計單位提出變更；監理工程師提出的設計變更；承包人提出的工程變更。      構成工程變更的主要事項：      （1）更改工程任何部分的標高、線型、位置和尺寸；（2）增減合同中給定的工作量、質量、工程的性質；（3）改變有關工程的施工時間和順序；（4）其他有關工程變更需要的附加工作。      2. 工程變更的確認及處理程序      2.1 工程變更的確認      由於工程變更會帶來工程造價和工期的變化，無論任何一方提出工程變更，均需由監理工程師確認並簽發工程變更指令。工程變更發生時，監理工程師要及時處理並確認工程變更的合理性。      2.2 工程變更的處理程序      認真處理好工程變更具有重要意義，一旦處理不好常會引起糾紛，損害業主和承包人的利益，首先容易使投資失控，為了適應競爭激烈的建設市場，承包人通常在投標或談判時讓步，而在工程實施過程中通過工程量的變化、索賠獲取補償，都有可能最終超出原來的投資；其次，工程變更容易引起停工、返工現象，對進度不利；第三，頻繁的變更還會增加監理工程師的協調工作量；另外對合同管理和質量控制也不利。因此對有效控制和管理非常重要。      這兩條公路為了加強對工程變更的管理，制定了工程變更的分類、審批許可權和審批程序。      （1）根據工程變更的內容和金額，將工程變更分為：小變更、一般變更、重要變更、重大變更。並根據分類確定監理組、駐地監理處、總監代表處、業主的審批許可權。      （2）變更的審批程序。為了更好地控制工程變更，所有變更應由申請的部門提出變更原因、圖紙和增減金額的報告，且均需監理工程師審查，並建立了完整的變更審批程序。詳見下面的框圖。      監理工程師審查變更時，無論哪一方提出的工程變更，都應與業主與承包人進行適當的協商，尤其是一些費用增加較多的工程變更項目，要與業主進行充分協商，徵得業主的同意才能批准。      由於某些特殊情況如按程序審批，有可能造成對工程的不利影響，烏一奎高速公路合同管理中規定：特殊情況可由有批准許可權的監理部門口頭批准，7天內由審批變更的部門書面確認並補齊變更手續。同時還規定業主書面批準的變更，由總監代表處簽發變更令。 3. 工程變更的估價與方法      3.1 工程變更的估價     3.1.2 估價的步驟      （1）監理工程師應得到業主批準的關於對規范或合同工程量所要進行的變更及費用估算和變更的依據和理由的授權，在FIDIC條款中已明確規定了監理工程師的權利。     （2）監理工程師在與承包人及業主協商後，由監理工程師商定一個合適的單價或價格，如協商不成，監理工程師決定一個其認為合適的單價或價格，並通知承包人及抄報業主。如果上述單價或價格未取得一致意見或決定之前，監理工程師可決定一個暫定單價或價格。     （3）監理工程師有確定單價的權力，但是工程量清單（包括計日工費率表）中的任何項目的單價或價格也不得作任何變更，除非該類變更單獨計算其價值已超過合同價的20%，以及該項下實際施工的工程量超過或少於原合同價已報價的合同工程量的25%。      3.1.2 超過15%的變更      如果監理工程師在簽發整個工程的移交證書時，發現由於工程變更和工程量清單上實際工程量的增加或減少（不包括暫定金額、計日工和價格調整），使合同價的增加或減少合計超過有效合同（指不包括暫定金額、計日工的合同價格）的15%，在監理工程師與業主和承包人協商後，應在合同價格中加上或減去承包人與監理工程師議定的一筆款額。若不能達成一致意見時，則由監理工程師考慮承包人的工地費用及總管理費開支，確定此數額（此數額僅以增加或減少有效合同的15%為基礎）。例如吐一烏一大高等級公路由於變更多，決算金額已超過合同價的15%，根據合同條款，監理工程師與業主、承包人協商後，調整了原合同價。      如當承包人接到變更指令後14天內不向監理工程師提出適當的變更單價和價格意向，將視為該變更不涉及合同價款的變更，不進行估價。因承包人自身原因（過失等）導致的工程變更，承包人無權追加工程款。      3.2 工程變更的估價方法      （1）合同中已有適用於變更工程的費率及價格，按合同已有的費率及價格計算、變更合同價款。      （2）合同只有類型似於變更工程的費率及價格，可參照此費率及價格確定變更單價，變更合同價款。      （3）合同中沒有適用或類似於變更工程的費率及價格，由承包人、監理工程師與業主適當商定後，由監理工程師和承包人商定一個合適的費率及價格作為結算的依據，如商定不成，監理工程師有權確定其認為合適的費率及價格。費率及價格確定的合適與否是導致承包人索賠的關鍵。      （4）監理工程師如認為必要或適宜時，可以指令任何變更工程按日工方法進行工程估價變更。對這類工作應按合同中包括的計日工作表中規定的項目及承包人在其投標書中對此所定的單價和價格支付承包人費用。      （5）監理工程師將確定的單價或價格意向通知承包人或承包人將單價或價格意向向監理工程師提出後，14天之內如監理工程師無不正當理由不確認或承包人無提出異議，均視為所提出的單價或價格意向自行生效。      4. 工程變更的支付     吐一烏一大高等級與烏一奎高速公路為了加強對工程變更的支付管理，規定無變更令的工程變更不予支付。當接到變更令，變更工程實施完畢後，經監理工程師確認後，在當月的中間計量中支付。    但在實際工作中，由於某些工程變更涉及金額大、施工期長等原因，為了加快施工進度，減少承包人的資金墊付，可以先根據監理工程師暫定的單價或價格，根據工程的進度先行予以支付。例如：上述例子中烏一奎高速公路新增的排水工程，實際支付中可暫按合同中的單價或類似的工程單價，以千米為單位，按實際施工進度先支付，再根據工程變更的批復進行修正。這樣就保證了承包人有資金投入後續工作，加快施工進度。但這樣同時增加了工程變更管理的難度，這就需要建立完善的工程變更台帳，根據批復的部門，按變更令的順序排列，做好變更支付的統計工作，避免漏計、重復計量。可利用計算機採用適當的軟體來進行這項工作，筆者使用Execl軟體進行變更統計工作，即清楚，又不會出錯，提高了工作效率。      5. 結束語      吐一烏一大高等級公路及烏一奎高速公路由於在工程變更管理中，方法得當，措施有利，執行嚴格，有效地控制了工程造價，取得了較好的效果。但有時由於工程變更審批過程中文件傳遞速度慢、部門間協調不及時等原因，造成時間上的延誤，建議在變更文件下發同時送達承包人及監理工程師，並定時召開由各部門參加的工程變更協調會，加快變更的審批速度
風險管理與管理信息系統建設
關於工程建設項目管理系統建設風險的討論越來越多了，風險以及風險管理這兩個概念，大家可能都有自己的理解，但是這種理解是否能夠成為一種共識，不得而知。因此，本文希望就這個問題進行一些有關的探討，旨在強化理解和增加它們在實際工作中的應用。什麼是風險?  盡管風險管理的理論已經有了幾十年的歷史，但由於風險的普遍存在以及風險管理在各個行業中的專門化，風險管理人員會根據自己特定的活動范圍，對風險給出不同的定義。對風險進行定義是必要的，它在一定程度上指出風險的對象和目標。下面給出有關風險的兩個定義。風險管理的經典著作《Risk Management and Insurance》將風險定義為：給定情況下那些可能發生的結果的差異性。保險理論中有關風險的定義為：風險是對被保險人的權益產生不利影響的意外事故發生的可能性。根據風險理論的研究，風險的一般性定義為人們對未來行為的不確定性而可能引起後果與預定目標發生的負偏差，這種負偏差是指在特定的客觀條件下，在特定的期間內，某一實際結果與預期結果可能發生差異的程度，差異程度越大，風險就越大，反之則風險越小。這種偏離可由兩個參數來描述：一個是偏離的可能性，即事件發生的概率；一個是發生偏離的方向和大小。因此，又可以將風險定義為：風險是某種不利事件或損失發生的概率及其後果的函數，可以用下列公式表示：R = f(P,C)(其中：R表示風險的大小；P表示不利事件或損失發生的概率；C表示該事件發生的後果，即偏離的方向或大小。)因此，綜上所述，我們可以將管理信息系統建設的風險定義為：在特定的條件及時間之內，管理信息系統建設的實際結果與系統建設預期的目標之間可能發生差異的程度。風險因素、風險事件和風險損失1、風險因素風險因素是指能增加或產生損失頻率和損失程度的因素，是對象風險產生的內在的、間接的原因。2、風險事件風險事件是指損失的直接原因或外在原因。風險之所以會導致損失，主要是因為風險事件的發生造成的；如果風險事件沒有發生，則不會導致風險損失。3、風險損失是指某一結果可能發生的與預期結果的負偏離或差異程度，所謂損失，在風險管理中是指對風險主體的非故意的，非計劃性的和非預期的某種價值的減少。這個定義中包括兩個重要要素：一是非故意的、非計劃性的和非預期的；二是價值的概念，這種價值不一定表現為經濟價值。缺少其中的任何一個要素，均不構成風險損失。
管理信息系統建設風險的特徵.風險的特徵是指風險的本質及其發生規律的表現。正確認識風險的特徵對於企業管理信息系統建立風險機制、加強風險管理、減少風險損失具有重要的意義。一、客觀性風險是一種普遍的客觀存在，人們既不能拒絕也不能否認它的存在。風險存在於客觀事件發展變化的整個過程中，無時不有無處不在。我們必須承認和正視風險的客觀存在，並且採取積極的態度，認真對待風險；二、可預測性風險是可以預測的。我們可以根據以往發生的類似事件的統計資料或者別人的經驗，通過分析和研究，對某種風險發生的可能及可能造成的危害進行預測和評價，在此基礎上進行風險控制和管理。管理信息系統建設的風險完全可以通過借鑒其它的系統建設的情況進行預測和判斷，對突出的風險因素進行控制。三、損失性風險的發生必然會導致損失。對於管理信息系統建設而言，風險造成損失是肯定的，而且這種損失有時侯很難估計它的大小，有的風險造成的損失對系統來說甚至可能是致命的，使系統建設完全歸於失敗，最後無法產生任何效益。四、結果的雙重性雖然管理信息系統建設的風險必然造成損失，但是如果能夠對這些風險進行有效的控制，可以變不利為有利，對系統質量帶來巨大的回報，甚至風險越大，克服風險後帶來的正面價值也越大。這就是所謂的「風險越高，利潤越豐」的道理。因此，對於管理信息系統來說，只要能夠對系統的主要風險因素進行有效的控制，一定可以收到意想不到的效果。從國內外發生的大量的事實可以看出，管理信息系統建設的風險管理能力在一定程度上決定了系統建設的成敗，其中的風險不僅表現在技術和基礎設施這些硬體方面的駕御能力，更加突出表現出來的是關於人、組織和制度方面的因素，對這些因素加強管理，找到問題發生的根本原因和有效的解決方法是成功的關鍵。
新產品開發中的風險評估 新產品開發是一個復雜的、動態的、連續的過程，其中涉及到大量的信息收集、分析、篩選及傳遞，各種模式方案的選擇與確定，各種要素資源的投入與配置，新產品生產及營銷戰略制定等一系列的工作.這些工作都不同程度地存在不確定性，從而導致企業新產品開發風險的發生。因此，要成功進行新產品開發，就必須加強對新產品開發中的風險分析與評估。風險辯識。對企業新產品開發風險評估，首先必須找出可能影響新產品開發成功的風險因素，研究各種風險因素會對新產品開發造成什麼樣的後果，該階段一般被稱為風險辯識，是進行任何風險評估的前提和基礎。企業新產品開發中的風險評估主要包括以下風險因素：技術風險。指企業在新產品開發過程中，因技術因素導致新產品開發失敗的可能性。技術風險大小由下列因素決定：技術成功的不確定性；技術前景的不確定性；技術效果的不確定性；技術壽命的不確定性。市場風險。指新產品的相對競爭優勢的不確定性，市場接受的時間、市場壽命及市場開發所需資源投入強度等難以確定，而導致新產品開發失敗的可能性。新產品開發出來以後，價格往往較貴，同時人們對新產品的質量、性能及其穩定性往往要觀望一段時間，或等別人使用後再購買，這就阻礙了新產品快速滲透並佔領市場。若新產品不能在短時間內佔領市場，則很可能失敗夭折。因為若這項技術也被競爭對手看中，他們很可能模仿並加以改進，在短時間內追趕上來，且其產品更具優勢。這時，剛剛被引導出來的市場，很可能被競爭對手佔領。資金風險。指因資金不能適時供應而導致新產品開發失敗的可能性。若不能及時供應資金，會使新產品開發活動停頓，其技術價值隨著時間的推移不斷貶值，甚至被後來的競爭對手超越，初始投入也就付之東流。此外通貨膨脹也會引起資金風險。環境風險。指新產品開發由於所處的社會環境、政策環境、法律環境等變化或由於自然災害而造成新產品開發失敗的可能性。因此，新產品開發，必須重視環境風險的分析和預測，採取有效的對策和措施，把環境風險減少到最小限度。生產風險。指在新產品開發過程中，由於生產系統中的有關因素及其變化的不確定性而導致新產品開發失敗的可能性。如難以實現大批量生產、生產周期過長、工藝不合理、設備和儀器損壞、檢測手段落後、產品質量難以保證、可靠性差、供應系統無法滿足批量生產的要求等。

❽ sap項目管理ps如何運用

網頁鏈接

網路文庫上就有，建議自己去看。

❾ SAP2000結構工程案例分析的介紹

《SAP2000結構工程案例分析》是由陳昌宏編寫，冶金工業出版社出版的一本書籍。