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

新的系统是怎样产生的？
回答很简单。或者是内部条件或者是外部条件，使业务的改变到了足够大的程度是产生新系统有足够的理由。这个变化可能来自于新的规则或计算方法，也可能来自于提高系统技术能力在竞争性的收益，或者来自于一直脱节（但相联系）的业务活动现
在要求有一个单一的统一的方法。

不管来源是什么，驱动力是变化，变化要求采取行动。但是不是当这些条件存在是一个系统项目就会出现呢？回答经常是否定的。只要在易于控制时，那些最接近业务活动的人将会经常反映和处理新的需要和要求。只有当一定的“舒适程度”被超越时，业务客户才寻求外部帮助。但是在这个变化周期的那个点上系统建造人员才能真正得到召唤并开始投身进去呢？

一个好一点的答案是当能处理已经认识到的业务需求的系统不再存在时，一个项目产生了。这是一个有力的促进因素，能很好的导致一个花费必要的资金和资源来创造一个理想的技术解决方案的决策产生。但是，意识到必须采取行动与决定行动的适当过程是两个截然不同的事情。

第一个决定还算简单，实际上它看起来可以在日常的基础上做出。“这个系统不再满足我们的要求”或“我们知道怎样自动化这个过程”都是在日常业务中所嘟囔的！在很多业务活动中，这个过程从未超出这一点。“存在太多的选择”或“不知道要采用的细节”或“业务细节现在还不能整理出来”都是延期的合理原因。

因此什么真正导致一个项目团队形成？通常，或者是坚持、或者是痛苦，或者是恐慌。

坚持

从事业务的人有一个有价值的观点或计划能表现真正的改进。这可能来自于一个个人或一个组织，或许拥有必要的决策/执行权力来采取独立的行动，也可能没有。但不管在哪种情况下，个人或组织能展开足够宽的支持基础来产生观点的行动。

痛苦

业务的境遇脱离控制很远，使它受副作用的影响。人们可能工作很长时间，业务正在失去顾客，或者是所需的运作信息的质量不充分。在任何情况下，不采取行动的危险在比重上已经超过了维持现状，行为认为是必须的。

恐慌

最后，业务境遇达到了危机的状态。业务量不再能控制，制定的规则使现在的系统失去作用，一个新的产品或服务被提出，或者是一个重要的人离开了公司。不管情况怎样，需要一个解决方案，同时时间是关键。

一个好的趋势是真正开始积极寻求新的系统项目的公司的数量。一个新的项目的开始可能是执行一个已有的长期系统计划的结果，或来自于一系列高层战略信息系统计划编制的建议。这些产生出的建造努力更多的倾向于基于公司的长期方向和目标，而不是由于针对商业危机或技术潮流而做出草率反应而产生的项目。

在这方面试图采取积极行动的组织应该考虑下面的问题：
“集中在公司的关键任务的目标上”
这使注意力直接集中在公司的业务需要上，而不是技术员的理想软件列表上。
回顾现在的应用情况，并根据它的业务性能和任何预计的未来的市场影响将每个系统分类。
这有利于最佳化当前整个系统基础组织的现有的投资。
整理业务和技术上的战略计划。
在现在精深的技术氛围中，单独存在的一项计划不能成功。任何技术支出应依赖于
业务需要，任何业务战略的变动应考虑需要的技术支持。
确保真正的战略方向制定者投入到这个过程中。

一些公司仅创建企业层模型来辅助长期系统计划。当目前的和未来的需求易于确定时，这些将变成真实的优秀的计划资源。然而，要注意的是在这个情况下这些努力是合适的。这个模型的潜在目的在贯穿于整个开发过程中：提供一个编制计划的辅助。对于分析员来说，陷入花费数年为一个计划建模而没有实际开发任何运作系统的陷阱。另一个要注意的是当模型完成时，它们正在变得过时。再一次，保持合理及集中的努力是为确定将来系统需求提供正确细节标准的关键。

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.

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有