<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" 
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>BPR 並非導入資訊系統後就萬事大吉</title>
<link>http://blog.roodo.com/rocksaying/archives/3106505.html/</link>
<description><![CDATA[Tags: 策略管理 BPR 分工 outsourcing
本文緣起於一篇討論資訊軟體委外課題的文章。雖是如此，本文的主題卻是組織管理、策略管理，而非軟體工程或資訊管理。


同人 閱讀我的《業務流程決定軟體程式，軟體程式追隨業務流程》之後，於《委外與流程整合》回應道 對於石頭成的這個結論，我並不能認同。雖然企業的核心業務流程不應該外包，但並不代表資訊技術在組織只有支援性的角色而沒有策略性的地位。

]]>
	</description>
<language>zh-tw</language>
<generator>Roodo Blog System</generator>
<copyright>All Rights Reserved</copyright>
<atom:link href="http://blog.roodo.com/rocksaying/archives/3106505-comment.xml" rel="self" type="application/rss+xml" />
<item>
	<title>回應：BPR 並非導入資訊系統後就萬事大吉</title>
	<description><![CDATA[說到成本，我任職的百貨流通業也自有一套計算方式。會隨著交易次數、商品數量與時間而不同。說穿了就是看公司跟客戶之間的「關係」決定成本。

這符合經濟學對成本，也就是價格的定義。價格是商品在買者與賣者之間的「關係」；價格不是商品的屬性。

以 Relationship database table 說明，則價格(price)不是商品表(Products)中的欄位。價格是商品表(Products)與客戶表(Customers)之間的多對多關聯表(ProductsToCustomers)中的欄位。

至於應不應該配合新的資訊系統改變原有的業務流程這問題，我在本文結論強調要先看企業對原有的業務流程了解多少。了解之後才能比較，才能知道如何吸納優點、消除缺點。]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/3106505.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/3106505.html#comment-10174973</guid>
		<category>文章回應</category>
	<pubDate>Thu, 03 May 2007 15:03:50 +0800</pubDate>
</item>
<item>
	<title>回應：BPR 並非導入資訊系統後就萬事大吉</title>
	<description><![CDATA[我舉個實例好了：
最近我在學著如何估算成本，尤其是供應商提供的成本。
簡單的說，每個產業都有「行規」，連成本計算也有！

而目前我看到的不同製程，光材料成本這一項計算，就不可能用一個結構性的表格來展現，已目前所知道的部份來說，可以分成底下幾類：

1. 材料淨重 x 材料單價
2. (材料淨重 + 固定數量 or 比例的重量) x 材料單價
3. 材料毛重 x 材料單價
4. 材料淨重 x 材料單價 x 某個特殊的比例數字

以上是單純就材料成本的計算，說實話，沒入行多年光憑道聽塗說或是看書，根本不可能了解這幾種材料計算的意義何在！
所以我比較贊同石頭的意見，但我認為第二種壞結果：
「為了配合軟體的使用，改變了企業內部原有的業務流程。」
不盡然完全是壞的。
這有可能是因為軟體的設計是參照某個最佳實務所建構的，而這個最佳實務的作法根據個案不同，有時的確比公司現行的作法好。
因此我覺得在導入外製的系統的過程中，多多少少還是會修改到現行的流程。]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/3106505.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/3106505.html#comment-10145919</guid>
	<author>HACGIS@gmail.com(tokimeki)</author>	<category>文章回應</category>
	<pubDate>Wed, 02 May 2007 23:31:13 +0800</pubDate>
</item>
<item>
	<title>回應：BPR 並非導入資訊系統後就萬事大吉</title>
	<description><![CDATA[以業務流程為主，這是沒什麼好懷疑的．

重點在解決問題的本質．這很多人都會說知道，但實際在執行的時候其實都不是這樣．

舉個例子，像很多提倡Agile的開發模式的外國Programmer常常都會說，只要用筆在白板上溝通整個系統設計，並不一定要用工具去畫一些UML的圖．(當然我並不是堅持不用工具@@a)

只是想說，很明顯，不管做什麼事，本來就該回到問題的本質去做，資訊科技很明顯在取代重複性工作非常強，搜尋資料也是，要抓住目前能解決的能力，在該用的地方去發揮才是．

我也好奇，跑去了同人那邊看了一下，對於裡面提到以下
「非資訊技術核心能耐的企業常不清楚....，也沒有辦法為企業創造價值」
這真的很有趣，如果站在是軟體開發公司的角度，這種問題真的出現在很多軟體公司吧．但我個人的想法是，這不是非資訊技術核心能耐的企業的錯，這種公司的任務重點在於清楚訂定需求，我覺得成敗最關鍵人物是軟體公司派去溝通需求這個人，這個人大部分的公司都是會從技術角度出發的，都會很酷的跟你說做不到，其實想一下就知道他是站在哪邊為出發點去做事情就知道會不會成功了，既然你是要開發人家的企業流程的資訊軟體，本來就跳進去熟悉人家的領域，把自己當為是客戶公司中的一員，在來思考資訊科技的支援．

如果以商人的角度出發，最佳解是錢都花在刀口上．其實以軟體公司來說，這樣對自己也是很有好處的，節省自己的時間，不必要去開發無意義的功能，以及不能幫助公司解決問題的功能．

不過我的概念還是回歸到做對的事情，根本的去解決問題．]]>
	</description>
	<link>http://blog.roodo.com/rocksaying/archives/3106505.html</link>
	<guid>http://blog.roodo.com/rocksaying/archives/3106505.html#comment-10144119</guid>
		<category>文章回應</category>
	<pubDate>Wed, 02 May 2007 22:21:36 +0800</pubDate>
</item>
</channel>
</rss>