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
So what is it that actually causes a project team to be formed? Usually, it is
either Perseverance, Pain, or Panic.
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.
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.
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
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
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.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-988560/，如需转载，请注明出处，否则将追究法律责任。