1995年8月26日，沙鋼CIMS工程正式立項，并與東南大學、江蘇省科委簽訂了聯合設計的技術合同，同時，沙鋼成立工程領導小組。而1993年11月沙鋼集團與華東冶金學院聯合創辦的“華沙自動化研究所”（以下簡稱華沙所）在其中則擔任了類似企業中計算機中心這樣的IT部門的角色。

選型從1995年開始，一直延續到了1997年，在整個過程中，數據庫選用ORACLE，基礎平臺的建設和潤忠公司的底層數據采集于連通等方案很快確定，大部分的時間都花在了ERP產品的選型上。一個參與過選型的工作人員說，主要擔心的是MRPII產品脫胎于制造行業，能否滿足鋼鐵這樣的流程行業需求，大家心里都沒有底。當時云集沙鋼的ORACLE、SAP、QAD、JDE和利瑪等廠商其實未必比他們的用戶心里塌實——ORACLE的應用產品沒有流程行業解決方案；SAP當時在國內鋼鐵行業尚無用戶（這兩個公司的鋼鐵行業解決方案當時都未推出）。而惠普公司當時也沒有國內鋼鐵企業SAP的實施經驗。

一位顧問的話或許準確地概括了當時的情景：“無論用戶、咨詢公司、廠商，大家當時都是摸著石頭過河。”就在這樣“摸石頭”的狀況下，當時沙鋼和專家組基本上達成一致，認為SAP+惠普的實施是一個比較可靠的方案。

1996年春節前，惠普作為項目總包，和沙鋼草簽協議，當時合同中的實施費用在200-300萬之間，硬件也使用惠普的產品，沙鋼購買了SAP的財務、生產制造、銷售、物料等幾個基本模塊，預備年后開始實施。

但是事情就在春節之后發生了180度的逆轉。一位ORACLE的銷售回憶，本來他們認為沙鋼的單子已經“沒戲了”。但是春節之后沙鋼找忽然到他們，說是要買ORACLE的應用軟件，作為回報，ORACLE給了沙鋼一個“很大的折扣”——數據庫白送。 就在1996年的這個春節里，究竟發生了些什么事情？

一位曾經親歷其事的惠普人士解釋說，惠普對這個合同評估到最后，認為實施金額價格太低，風險卻太大，因此萌生退意。風險除去當時惠普的顧問中沒人做過SAP的鋼鐵行業用戶外，主要是由于沙鋼在條約中加進了一個懲罰性條款，要求惠普保證項目在6個月左右實施完畢，否則將要追究責任。惠普要求把該條款去除，沙鋼出于保護自己利益的角度考慮沒有同意，于是導致了惠普和SAP的退出。

惠普和SAP的退出實際上讓沙鋼失去了選擇，一位當事人回憶說，當時的沙鋼項目組負責人在和惠普人談判破裂之際說：“SAP上午從沙鋼走出去，ORACLE下午就會進來。”此語固然可以做他解，也包含了幾分無奈。

接下來的故事是人人盡知的大結局——沙鋼購買了ORACLE的應用產品10.6，并從ORACLE和當時的實施伙伴漢得那里購買了一部分培訓（從漢得處購買的30天培訓甚至沒有用完），然后便開始了信息化的征程。

在沙鋼與SAP的失之交臂過程中，有一點值得注意——一位項目組成員承認，省CIMS專家組當時認為沙鋼的選型時間拖的過長，這可能無形中為沙鋼是否能在1998年年底之前完成實施并通過驗收帶來了無形的壓力。這有可能是導致在“6個月”實施時間的問題上，雙方無法達成協議的原因之一。

一位當年參加談判的實施顧問則評論說：“這說明大家都沒有經驗。”——沙鋼這樣的項目，如果要按照理想狀態實施完畢，6個月是不可能的。

沙鋼的人也承認，當時他們對于項目的估計，“過于樂觀”。

不見不散項目組

“選擇ORACLE之后，對于沙鋼華沙所的技術人員來講，是幸也是不幸。”

到了2003年重新選擇SAP后，該所經歷了整個信息化過程的人回顧5年來的經歷，終于說出了這樣一句話。

他的意思是，幸運的是，ORACLE的開發工具并未辜負這些程序員的期望。不幸的恰恰也是，ORACLE的開發工具太好用了。 一位后來去過沙鋼的ORACLE顧問這樣形容沙鋼的應用狀況：“后來ORACLE的大部分模塊都被棄用了，實際上沙鋼是在ORACLE平臺上掛了大量自主開發應用軟件。這些軟件和ORACLE軟件的比例大概是8：2。”

造成這個結果的原因是多方面的。主要的問題是，在1998年沙鋼ERP上線的時候，其實就并未形成一個完整的閉環——當時是庫存、采購模塊先上線。由于ORACLE的財務報表不符合財務習慣，并且尚未得到財政部審批和一些國內企業眾所周知的障礙，ERP中的總帳模塊沒有上，應收應付模塊也只用了一部分。固然銷售、庫存、應收和采購、庫存、應付這兩條線按照沙鋼人的說法“能夠跑通”，但是由于財務模塊不連通，使得各個模塊的應用的作只能等同于局部的流程優化和電算化，而沒有形成由定單驅動的價值鏈循環。這樣做，即使有效果，好也有限——就像項目組的人所說：“總帳不上，應收應付管那么細也沒有用。”值得注意的是，除了質量管理、數據采集、廢鋼管理等一些原有的自主開發的軟件之外，華沙所對一些“和廠里現有流程不匹配的應用”做了重新開發。 這就解釋了沙鋼人因何發出感慨——ORACLE的開發工具使得沙鋼人能夠實時靈活地按照企業現有需求來開發應用，但是正是因為想怎么改就怎么改，使得ORACLE產品中被固定在模塊中的管理理念含量被大大沖淡，甚至抵消了。