新的系統是怎樣產生的？（軟工系列文章之六） (轉)

新的系統是怎樣產生的？（軟工系列文章之六） (轉)[@more@]

How are New Systems Born?
By Russ Finney
新的是怎樣產生的？
  回答很簡單。或者是內部條件或者是外部條件，使業務的改變到了足夠大的程度是
產生新系統有足夠的理由。這個變化可能來自於新的規則或計算方法，也可能來自於
提高系統技術能力在競爭性的收益，或者來自於一直脫節（但相聯絡）的業務活動現
在要求有一個單一的統一的方法。
  不管來源是什麼，力是變化，變化要求採取行動。但是不是當這些條件存在是
一個系統專案就會出現呢？回答經常是否定的。只要在易於控制時，那些最接近業務
活動的人將會經常反映和處理新的需要和要求。只有當一定的“舒適程度”被超越
時，業務客戶才尋求外部幫助。但是在這個變化週期的那個點上系統建造人員才能真
正得到召喚並開始投身進去呢？
  一個好一點的答案是當能處理已經認識到的業務需求的系統不再存在時，一個專案
產生了。這是一個有力的促進因素，能很好的導致一個花費必要的資金和資源來創造
一個理想的技術解決方案的決策產生。但是，意識到必須採取行動與決定行動的適當
過程是兩個截然不同的事情。
  第一個決定還算簡單，實際上它看起來可以在日常的基礎上做出。“這個系統不再
滿足我們的要求”或“我們知道怎樣自動化這個過程”都是在日常業務中所嘟囔的！
在很多業務活動中，這個過程從未超出這一點。“存在太多的選擇”或“不知道要採
用的細節”或“業務細節現在還不能整理出來”都是延期的合理原因。
  因此什麼真正導致一個專案團隊形成？通常，或者是堅持、或者是痛苦，或者是恐
慌。
  堅持
  從事業務的人有一個有價值的觀點或計劃能表現真正的改進。這可能來自於一個個
人或一個組織，或許擁有必要的決策/權力來採取獨立的行動，也可能沒有。但不
管在哪種情況下，個人或組織能展開足夠寬的支援基礎來產生觀點的行動。
  痛苦
  業務的境遇脫離控制很遠，使它受副作用的影響。人們可能工作很長時間，業務正
在失去顧客，或者是所需的運作資訊的質量不充分。在任何情況下，不採取行動的危
險在比重上已經超過了維持現狀，行為認為是必須的。
  恐慌
  最後，業務境遇達到了危機的狀態。業務量不再能控制，制定的規則使現在的系統
失去作用，一個新的產品或服務被提出，或者是一個重要的人離開了公司。不管情況
怎樣，需要一個解決方案，同時時間是關鍵。
  一個好的趨勢是真正開始積極尋求新的系統專案的公司的數量。一個新的專案的開
始可能是執行一個已有的長期系統計劃的結果，或來自於一系列高層戰略資訊系統計
劃編制的建議。這些產生出的建造努力更多的傾向於基於公司的長期方向和目標，而
不是由於針對商業危機或技術潮流而做出草率反應而產生的專案。
  在這方面試圖採取積極行動的組織應該考慮下面的問題：
  “集中在公司的關鍵任務的目標上”
  這使注意力直接集中在公司的業務需要上，而不是技術員的理想列表上。
  回顧現在的應用情況，並根據它的業務和任何預計的未來的市場影響將每個系
統分類。
  這有利於最佳化當前整個系統基礎組織的現有的投資。
  整理業務和技術上的戰略計劃。
  在現在精深的技術氛圍中，單獨存在的一項計劃不能成功。任何技術支出應依賴於
業務需要，任何業務戰略的變動應考慮需要的技術支援。
  確保真正的戰略方向制定者投入到這個過程中。
  一些公司僅建立企業層模型來輔助長期系統計劃。當目前的和未來的需求易於確定
時，這些將變成真實的優秀的計劃資源。然而，要注意的是在這個情況下這些努力是
合適的。這個模型的潛在目的在貫穿於整個開發過程中：提供一個編制計劃的輔助。
對於分析員來說，陷入花費數年為一個計劃建模而沒有實際開發任何運作系統的陷
阱。另一個要注意的是當模型完成時，它們正在變得過時。再一次，保持合理及集中
的努力是為確定將來系統需求提供正確細節標準的關鍵。

 

How are New Systems Born?
By Russ Finney
 
The answer is simple. Conditions either within, or external to the business
change at a dramatic enough level to warrant action. This change may be in the
foof new regulations or accounting methods, it may be in the form of a
perceived competitive advantage from enhanced system technological capabilities,
or it may be in the form of a perpetuation of disjointed (but related) business
processes which now require a single unified approach.
 
Whatever the , the driving force is change, and the change is demanding
action. But does a systems project always up whenever these conditions
exist? The answer more often than not is no. Those in the business who are the
closest to the situation will usually react and cope with the new needs and
requirements as long as they have a comfortable feeling of control. It is when a
certain "comfort level" is exceeded that the business client may seek outs
help. But at what point in this change cycle do the system builders actually get
the call and become involved?
 
A better answer may be that a project is born when a system no longer exists
which can handle perceived business requirements. This is a powerful motivator
which very well could result in a decision to expend the ctal and the
resources necessary to create the desired technological solution. However, the
realization that action must be taken, versus actually detening the proper
course of that action, are two truly distinct and different matters.
 
The first decision is fairly easy, in fact it is one that seems be made on a
daily basis. "This system is no longer meeting our needs", or "we have got to
somehow automate this process" are s uttered in businesses every day! The
second decision, choosing the appropriate solution, is the real show stopper. In
a vast number of businesses, the process never gets beyond this point. "Just too
many options exist", or the "technical know how is not available", or "the
business know how can not be marshaled at this time" are all valid reasons for
delay.
 
So what is it that actually causes a project team to be formed? Usually, it is
either Perseverance, Pain, or Panic.
 
Perseverance
 
Someone within the business has an idea or a plan with merit which represents
genuine improvement. It may be from an individual or a group, who may or may not
possess the decision/implementation authority necessary to take independent
action. But in any case, the individual or the group is able to develop a broad
enough base of support to generate action on the idea.
 
Pain
 
The business situation is just far enough out of control that it is having a
negative effect. People may be working long hours, the business may be losing
customers, or the quality of required operational information may be inadequate.
In any case, the risk of inaction begins to outweigh remaining within the
current status quo and action is deemed necessary.
 
Panic
 
Finally, a business situation hits the critical state. Business volume can no
longer be managed, a regulation is enacted which invalidates the current system,
a new product or service is offered, or a key individual leaves the company.
Whatever the circumstances, a solution is required, and time is of the essence!
 
One positive trend is the number of companies which are actually becoming more
proactive in chartering new systems projects. A new project may be started as a
result of the implementation of a existing long-range systems plan, or as a
recommendation from a series of high level strategic information systems
planning sessions. These resulting system building efforts tend to be much more
grounded in the long-term direction and goals of the company than projects which
are born as a hasty reaction to a business crisis or technological fad.
 
An organization which is attempting to be proactive in this regard should keep
the following considerations in mind:
 
  "Focus on the mission-critical ives of the company."
 
This keeps the attention centered squarely the business needs of the company
rather than the software wish lists of the technicians.
 
Review the current application portfolio and classify each system based on it's
current business performance as well as any anticipated future business impacts.
 
This helps to maximize the existing investment in the current corporate systems
infrastructure.
 
Align business and technical strategic plans.
 
In today's technology intensive environment, one plan can no longer succesully
exist without the other. Any technology expenditures should depend on business
needs, and any business strategic changes should take into account the required
technological support.
 
Insure that the individuals who are the true "strategic direction setters" are
involved in the process.
 
A planning process based on the guess-work of those who report to the decision
makers can result in the creation of dead-end projects, misguided efforts, and
needless frustration for everyone.
 
Some companies are going even so far as the creation of enterprise level models
to aid with long-term systems planning. These tend to be truly lent
planning resources since both critical needs and future needs can be readily
identified. However, one caution about these efforts is appropriate in this
context. The underlying purpose of the models should be kept in mind throughout
their development: to provide a planning aid. It is very easy for the analysts
to fall into the trap of spending years modeling the enterprise without actually
develo any working systems. An additional concern is that as soon as the
models are complete they are already beginning to become out of date. Once
again, keeping the effort reasonable and focused is the key to providing the
correct level of detail for identifying future system needs.