10月 29, 2004

如何選擇適當的開發工具建構網路應用系統(一)

長期以來,資訊產業一直面臨著與時間賽跑考驗,全球資訊服務業龍頭的IBM,其2001年全球服務事業(Global Services)已佔總營收四成以上,日系大廠富士通計畫在2002年三月前將日本國內幾處硬體工廠轉為軟體研發與企業資訊服務據點,並成立新的軟體服務事業中心,國內資訊大廠宏碁和大眾也於2001年10月時分別提出「微巨營運服務」與「易化服務」架構,事業重心由電腦硬體製造轉型為電子化應用資訊服務。
Web Services網路服務已成趨勢
在硬體產品生命週期日漸縮短,獲利節節下滑,而資訊服務獲利反而逆勢上揚的情況之下,由硬體事業轉向以軟體與服務為重心,替企業架構全球化經營所需的運籌管理與電子商務平台,已經被國際資訊大廠視為尋求永續生存的一道活泉,也是整體資訊產業發展的大勢所趨。
近年全球在美國網路泡沫化與高科技公司股價大崩盤所引發的經濟不景氣中,連帶受到相當的波及,加上九一一恐怖事件,更讓全球經濟雪上加霜。值此一波資訊產業嚴重受創下,國內資訊服務業的表現也不盡理想,究其原因為:國內企業用戶市場主要來自製造業、金融業、流通業等,當個別產業營運負成長時,會延緩電子化的步伐,導致部份項目暫停或延後,或經費縮減,而軟體業者或系統整合商也因此無法獲得訂單,或以低於成本價格接受訂單。
但2001年國內資訊軟體市場仍有幾個高成長業別,包括:資訊安全軟體與服務(Information Security Service Provider)、ISP(Internet Service Provider)之寬頻接取業務,以及線上遊戲(Online Game)等;受到景氣影響導致僅有低成長的業別包括:E-Business相關軟體,以製造業為主的ERP與SCM系統,以金融業與流通業為主的CRM(Customer Relationship Management)系統等。而2000年非常熱門的ASP(Application Service Provider)、IDC(Internet Data Center)市場,在國內資訊委外服務環境尚未成熟之際,2001年更難有所表現,因而多數業者均轉為以提供系統整合或專業服務為主。
然而當前資訊服務業的經營以全然不同於過去以低價和規模經濟取勝的硬體製造,而是在於廣泛性(Generally)、即時性(Immediately)、效率化(Efficiency)、市場力(Marketing Strength),就上述特色唯有網路架構應用系統方能提供。

...待續

10月 28, 2004

營建產業E化策略初探(四)

終於,向前跨出一步了嗎?
近來國內多家營建業者紛紛宣告將朝電子商務領域發展,並紛紛延攬網路或軟體業裡卓然有成的高手擔任企業網路化的重任。姑且不論這樣的改變究竟會不會帶領業界邁向第二春,或者只是上市公司為了炫惑投資人的目光而採用的障眼法,可以預見的是未來的幾個月裡將有無數的業界菁英轉投電子商務的懷抱。
這樣的情形令筆者想起在八十一年至八十五年期間,營建業者為了搶搭上市上櫃列車,紛紛延攬證券業菁英進入管理經營階層,並積極採用各種操作手段炒作股票,筆者便曾親眼目睹一位以炒作股票聞名的證券菁英,如何地將一個原本腳踏實地,體質良好並素有名聲的建設公司,搞到現在鉅額虧損難以彌補的境地。
這樣一個改變算不算是向前跨出一步了?值得觀察。
首先,營建產業這個龐大複雜的恐龍實非習慣於單純環境的網路菁英所能理解的,如果為趕潮流或炒作題材而進行E化工程,其結果恐怕只是架個網站做個宣傳,把網際網路當作是一個新型式的電子廣告媒體,或是高薪找來的工程師只為了多承攬一項光纖網路的架設工程,其成本與效益之間實在不成比例。
其次,營建業者迫不急待地引進才剛萌芽的電子商務,說句實話是因為狗急跳牆,長期的虧損讓老闆們朝不保夕,在病急亂投醫的心理因素下,網路被視為一帖萬靈丹,而對於瞎子摸象般的網路菁英而言,投入這一場豪賭裡,恐怕將難以全身而退了。
再者,營建產業現存的管理階層多是經歷了各種基層工作,逐步攀爬至目前的地位,這些人多半對網路科技一知半解,電腦往往只是一個較為方便的打字工具,甚至於淪為主管桌上的裝飾品或是上班時間偷懶的玩具,筆者便曾目睹一家營運尚稱良善的公司,高層主管桌上的電腦一天之中恐怕難得開上一回,像這樣的情形其實比比皆是,想要在營建產業中推動E化工程,組織中的抗拒力量將難以想像。
其實,雖然以上種種問題似乎澆了有心改變的業者一桶無情的冷水,傳統產業進行E化工程卻是一個必然的結果,面對鋪天蓋地而來的網路浪潮,將可預見對所有產業所造成的衝擊。
傳統產業E化工程將是一個漫長而艱辛的工作,誰也不能保證一定成功,但是不做將被淘汰,因此更需要專業菁英的投入。接下來,筆者將根據這幾年觀察所得及接觸並投入網路商務心得,針對營建產業E化策略做進一步的探討。

...待續

撰稿者/ 建築師 謝季中

營建產業E化策略初探(三)

營建產業的兩難問題
在這個網路時代裡,傳統產業面臨著越來越大的競爭壓力,和越來越微薄的利潤空間,一般的製造業及零售業還可以藉由網際網路打造新的通路,服務業則可以透過網路提供各種加值服務,雖然從表面上來看,似乎都有其解決之道,但是或多或少都面臨著一些兩難的問題。
相較之下,國內營建產業所面臨的幾個兩難問題來的嚴重許多,這也事業者們雖已逐漸明白網路的威脅,卻又遲遲無法因應改變的主因。營建業所面臨的兩難問題大致上可以歸類為:
◎經濟基礎的兩難----過去營建產業得以獲取高利潤的主要經濟因素在於都市化的結果,由於都市人口的集中帶來土地開發利益,在土地資源相對稀少的情形下,一個好區為的建築個案往往可以讓業者及地主帶來可觀的利潤。然而新經濟和新科技讓此一情形完全改觀,土地不再是關鍵生產因素,知識生產力取代土地成為主要的經濟因素,可是,失去土地開發價值的營建業應該叫做什麼?
◎商業模式的兩難----國內營建環境最讓人詬病的莫過於公共工程的圍標及綁標,更因為每年超過三千億的工程利益而成為黑白兩道競相爭食的大餅。由於營建的決策過程中,充斥著利益交換的黑箱,與本質上屬於公開透明的網路特性,存在著格格不入的衝突,更因為網路化所帶來的衝擊將直接而明顯的影響既得利益者的優勢,這場營建產業E化潮流將會是精彩可期的戰爭。
◎產品特性上的兩難問題----傳統上,營建個案屬性不會完全相同,影響品質優劣的因素過多,生產時程過長,無論是在採購發包或是品質管理均難以像一般製造業一樣的標準化,更由於產品具有時空的唯一性及不可移動性,無法重複消費及傳遞,難以將現行以買賣行為為主的電子商務模式硬套至營建業裡。
◎角色定位的兩難問題----從營建業者過去層層轉包的機制來看,實際上是一個集團式的中介商角色,網路興起所帶來的去中介化效應將從根本上威脅營建業者的存在價值,所以普遍抱持著觀望及抗拒的態度,然而隨著網路發展現在亦已逐漸面臨不得不做改變的時候了。
◎組織型態的兩難問題----基本上,營建產業非常容易陷入組織不當膨脹的循環,過去為了增加承攬工程數量及應付專業技術人員的高流動率,營建企業必須不斷的增加人員,而逐漸膨脹的組織需要更多的案源支撐,因此造就了以案養案的特殊產業環境,在景氣良好或尚可時期還不至於出現問題,但在長期景氣不佳或低迷時,往往因為一個個案或環節而產生缺口,稍一不慎便會產生骨牌效應而一夕崩潰,因此大型的營建企業均發展出極為複雜的組織型態與管理控制方式,以因應來自組織型態上的壓力。在這樣的組織架構下,網際網路所產生的新經濟對這些組織管理者而言,將不只是一個挑戰,恐怕會成為一個災難的開始。

...待續

營建產業E化策略初探(二)

經過這兩年來的觀察,營建業者普遍存在了幾個似是而非迷思:
◎網際網路是屬於新興產業的工具,與建築營造這個古老的行業無關。(這也太妄自菲薄了!)
◎網路事業是燒錢的行業,投入電子商務對營建業沒有直接的效益,等別人成功了再把模式拷貝過來。(一笑!!)
◎營建個案特性不同,缺少標準化機制,頂多是在網頁上打打個案廣告或是公司產品介紹。(目前最常見的作法。)
◎非得發展網路不可嗎?目前仍可以活得很好,何必自找麻煩?
◎資訊技術還不足以解決營建產業的『所有』問題,等技術更成熟了再說。(典型的鴕鳥心態)
◎建築設計是一種創意工作,不是網路技術所能替代的,所以網路對營建業幾乎是沒有用處。(建築師們的普遍心態)
現在,在環境的逼迫下這些情形多少有些改變,但是一般來說,喊口號的總比真正瞭解並實行的人多。如果有人問營建業者是否會朝網路發展,十個總有十一個會,但是很多業者不知道的是網路化的後果可能是傳統實體組織的解體,管理機制重塑及改變遊戲規則,這樣的代價是否為每個業者所能承擔的?
更深一層來說,網路及電子商務所挑戰的是價值體系的改變,是一種全新的視野,正如同管理大師彼得‧杜拉克在『二十一世紀的管理挑戰』一書中所說的:這是一種新的心靈版圖的拓展。
回顧這幾個月來在網路知識與技術上的學習歷程,在這個領域中我還算是一個新鮮人,未來還有很長的一段路要努力。許多觀念其實和所有人一樣還在摸索當中,但是,就像當時轉入企業管理領域時的心情一樣,在拓展新的心靈版圖的同時,我將把自己投入在網路商機中的所見所得,融合對營建產業的認識及傳統經濟學的知識,透過網路與所有人分享。

...待續

營建產業E化策略初探(一)

緣起--希望與夢幻
網際網路和電子商務在過去兩年來無疑地帶來許多成功與致富的機會,每個星期都有為數驚人的新網站在全世界各地成立,雖然今年以來許多網站紛紛以倒閉收場,但是網路魅力依舊無人能檔。
不可諱言的,網際網路提供許多年輕人邁向創業成功的道路,雖然最後能夠揚名立萬的人畢竟是少數,但是在這一股新經濟的潮流之下,似乎已經沒有人可以置身事外。對於這一股潮流,許多傳統產業的從業人員和老闆真是看在眼裡,酸在心裡,相信更有許多人幸災樂禍地看著這一次的網路泡沫破裂而安慰地認為新經濟只是一場夢幻。
這真的只是一場夢幻嗎?還是傳統產業脫胎換骨的希望?即使以筆者早在八十三年間就開始接觸並使用網路,並利用遠端資料庫完成碩士論文,但在八十七年重新接觸網路時,亦曾質疑網路的經濟效益。由於營建產業一直是傳統產業的龍頭,近幾年雖然每況愈下,但身居於這個產業中,網路似乎仍是一個毫不相干的領域。
事實上,營建產業領域裡的所有人,包含老闆與員工,他們所存在的資訊焦慮可以說是各業之冠,眼睜睜的看著這一波成長將營造業摒除在外,多年累積的不景氣和資金缺口雪上加霜地緊追在後,眼看著指數日上而股價日跌,箇中的辛酸恐怕不是其他產業所能想像的。
為了趕搭這一班列車,許多怪異的解決方案紛紛出籠:有的轉投資高科技產業,有的成立網路子公司,有的乾脆更名為某某數位科技公司,這些行為就像幾年前營建產業一窩蜂地宣布通過ISO認證一樣可笑,試問這些號稱具有國際認證的營建企業現在的情形如何?有多少家在連年虧損與生死存亡間掙扎?錯的不是工具本身,而是企業主錯誤的心態與觀念。

...待續

網路架構應用系統開發工具之健檢(五)

工欲善其事 必先利其器
網路架構應用系統包含的應用層面甚廣,舉凡所有資料庫導向的網頁程式皆屬之,如:企業入口網站、網路客服、客戶關係管理、企業知識管理)及行動化方案等。如何選擇一個良好的開發工具呢?至少有三點是必備的:
1.能快速建立資料庫,提供支援的資料庫包括SQL、MS Access、FoxPro等,並可透過ODBC、OLEDB等來連結。
2.能快速的產生程式原始碼,包括ASP及HTML甚至JSP、PHP及ASP.NET。
3.可自動產生專案系統文件,包括專案資訊文件、MTX文件、頁面清單文件、報表清單文件、頁面功能文件、頁面設計文件、資料表格清單文件等系統分析文件。
應用開發工具的目的即在於便捷、效率及正確的開發應用系統,所以正確的選用開發工具,可使應用系統開發工作能事半功倍。

本文刊載於 財團法人資訊工業策進會 資訊與電腦出版社 『網路通訊』雜誌 2002年8月號133期
本文作者 Andy Lung
曾任:亞昕資訊股份有限公司 總經理特別助理
現任:易設易舍網 創意技術總監

網路架構應用系統開發工具之健檢(四)

而針對這樣的特性及開發需求,開發工具就須分為4部基礎作用引擎。
1.程式編碼引擎(Coding Engine Module):為程式碼產生之部份,包含操作模組(介面、檔案管理、序號、功能管理、參數設定)、元件模組(COM+管理、佈景管理、CCS管理、Menu管理)、支援模組(跨平台支援、程式精靈)。
2.資料庫引擎(Data Engine):為應用程式資料庫產生或關聯之部份,包含操作模組(介面、檔案管理、序號、功能管理、參數設定)、資料庫模組(結構建立、表單管理、巨集管理、關聯產生)、支援模組(跨平台支援、程式精靈)。
3.系統文件引擎(Document Engine):為應用程式相關技術文件產生之部份,包含操作模組(介面、檔案管理、序號、功能管理、參數設定)、分析模組(系統分析、流程管理、程式結構模組、文件產生)、支援模組(跨平台支援、程式精靈)。
4.報表引擎(Report Engine):為應用系統需求報表產生之部份,包含操作模組(介面、檔案管理、序號、功能管理、參數設定)、編輯模組(報表管理、格式管理、報表產生)、支援模組(跨平台支援、程式精靈)。
核心引擎與各子引擎或相關模組之呼應關聯均以XML技術做文件交換產生;從前的EDI標準,是以超文件標記語言(HTML)為主流,然而並不具支援多媒體與電子商務彈性,再加上單向連結架構過於原始,對強調網路互動及快速反應等新網路應用系統模式的需求而言,已不敷使用,因此發展出XML,成為新的EDI標準。在XML架構中,程式設計者可依系統間甚至模組間彼此特殊需求,而於資料前標示種類語言,具有語言延伸性,可在異質環境中取得相關資訊。加上目前的全球軟體大廠如Microsoft、Oracle、Adobe、HP、Sun與Netscape等均提供相關技術支援,讓XML更增加作業平台與資料庫的相容性。而XML所具備的跨作業平台、不同資料庫資料直接交換及無限擴充的特性,使資料探勘(Data Mining)能發揮強大的功能,成為開發能力強大的網路架構應用系統開發工具。

...待續

網路架構應用系統開發工具之健檢(三)

最佳幫手 - 程式產生器
但是要快速有效地完成網路架構應用系統,需要適當的開發工具,於是程式產生器便應運而生。所謂的程式產生器,就是利用簡單的設定及圖形介面的拖曳方式,即可快速自動產生程式原始碼。而簡單的程式產生器,是無法提供當前快速蓬勃發展的網路電子化應用;一個完整的網路架構應用系統開發,除了程式碼的產生,更重要的是資料庫的建置、整體專案的一致性及專案系統文件的建立;亦即程式撰寫只是系統開發的一小部分,一套能提供完整的開發工具,才是目前最殷切的期待。
應具備之要件
完整的網路架構應用系統開發工具該具備哪些條件?
1.簡化開發環境以輕易組合、選取、拖曳的方式,輕鬆建立網頁資料庫及網路架構應用系統程式。
2.能在極短的時間內,完成開發動態、資料庫導向的網站,取代以往冗長耗時的開發時程。
3.撰寫程式不必辛辛苦苦地逐行撰寫程式、逐一表單欄位地建構資料庫結構、一字一句地編寫專案系統文件,就能架構功能強大的網路架構應用程式。
能以最迅速、簡單的方式,來產生存取、更新等即時性功能的網頁應用程式原始碼與資料庫;如此一來,無論是程式設計師、網頁開發人員、企劃人員、網路管理人員甚至學生,只需要懂一些資料庫的觀念,就可容易地的藉由開發工具來開發web-based網際網路應用程式。

...待續

網路架構應用系統開發工具之健檢(二)

何謂網路架構應用系統
大多數的企業主都認同,內部管理及對外行銷業務體系的網路化是趨勢所在,否則將喪失競爭力而遭淘汰。不過傳統的視窗應用軟體環境,所有的資料都被儲存在特定的電腦裡,一但邁出公司大門,就無法從外部連回執行業務。但是如果以瀏覽器介面取代傳統的視窗應用環境,藉由網站的訊息中心架構企業的數位神經系統,則所有的企業相關訊息往來,都可以在網站的訊息中心作交換、歸檔及調閱;決策者可隨時隨地監督企業內部的訊息流動,員工不論身在何處,都可利用瀏覽器連上網路電腦,進入公司網站來處理日常工作。企業網站將成為對外、對內的資訊交流及管理平台,員工的日常工作環境都被整合到這裡,也可以在家上班或以虛擬團隊協力完成一項任務,而主管也可遠端遙控監督公司狀況,並下決策指示。
企業網站在發展的過程中,應該要常常思索,當您身處世界各地時,如何仍能即時透過網路連回公司資料庫,取得經營所需之資訊與下決策?如何知道員工跟客戶溝通的細節是否妥當?客戶有哪些抱怨被員工忽略?客戶如何透過網站取得更即時、互動的服務?
網路架構應用系統(Web-based Application System)即是因應上述需求而生,主要以整合各種訊息流動的神經網絡,結合企業內部資訊管理、對外網站內容管理及往來的客戶/廠商聯絡,創造出網路世代的全方位管理應用系統。

...待續

網路架構應用系統開發工具之健檢(一)

在無法抵擋的e化趨勢下,透過網路基礎架構提供一系列軟體服務,讓各式的電子裝置,在任何時間、地點都可自由地擷取資訊,共享網路資源。但這都得靠網路軟體應用系統之開發,而網路架構應用系統開發工具的研發,便是提供開發者一個事半功倍的利器,本文將告訴您如何來檢測。隨著多元化Non-PC裝置的推陳出新以及企業e化的盛行,從網路上存取應用軟體(Web-based Application Program)已經逐漸成為未來網路服務的主軸,像是IBM的Pervasive Computing、Sun Microsystems的Sun One、Microsoft的 .NET等,國際資訊廠商所提出的事業藍圖,都是透過網路基礎架構提供一系列軟體服務,讓各式的電子裝置,能在任何時間、地點自由地擷取資訊,共同分享網路資源;也讓企業系統易於彈性整合,經由網路調整系統功能,應用系統的開發與維護將變得更為容易,並可迅速滿足客戶需求。

這種新興的網路應用型態,將是各家資訊服務業者爭相競逐的戰場;商機固然無窮,資源整合能力的挑戰亦十分艱鉅。所以如何有效利用工具來完成網路架構應用系統的開發?是業者不得不思量的重要課題。

...待續

10月 26, 2004

研發技術累積與提昇的基礎 -- PDM / PLM (一)

近年來台灣亦掀起一陣PDM / PLM風潮,希望藉由資訊應用系統的協助,提升台灣產業國際競爭力,漸由製造整合能力轉為新產品研發之創新能力。

PDM / PLM的緣起
產品資料管理之緣起約在1985年,早期是使用在航太工業。當時波音公司(Boeing)希望能藉著過去的經驗、文件資料、快速研發,發現下述現象:
資料量及儲存空間太大、資料搜尋不易、資料遺失或不完整、無法找到各文件資料之有效版本、資料之再利用價值低。
為了解決以上問題提升資料之再利用價值,波音陸續投入資訊系統的開發,建置產品資料管理電子化系統。



What is PDM / PLM
產品研發管理PDM(Product Development Management)系統是以產品為中心的研發協同工作平台,分類、搜集產品生命週期中所產出之技術文件、圖檔、表單,並追蹤、分析產品生命週期內所產生之相關資訊,以避免資訊誤用與資料一致性,提昇產品品質、縮短設計時間、減少變更錯誤,以提升產品資料之再利用價值。
PDM系統與ERP、CRM…等企業資訊應用系統的整合,可將產品資料與整個企業資訊系統共同分享利用,即可從產品研發到生產、製造、銷售、維護、服務的管理,實現完整的產品生命週期管理即PLM(Product Lifecycle Management)。

...待續