新的系统是怎样产生的？（软工系列文章之六）

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
form of 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 source, the driving force is change, and the change is demanding
action. But does a systems project always spring 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 outside
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 capital and the
resources necessary to create the desired technological solution. However, the
realization that action must be taken, versus actually determining 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 words 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 objectives 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 successfully
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 excellent
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
developing 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.