The Business Analyst
by Richard C. Robinson
Companies today rely upon technology, not only for infrustructure, but
also to provide value-added services to their clients. Technology in this
way is becoming an increasingly important resource that needs to be
managed properly.
Technology solutions no longer come "out of the box" as often as they once
did. And of those
that do, they usually need to be highly customizable. Whether a company
is developing
it's own software and systems or purchasing from a vendor, there is a need
to be sure that the design and development process is not run by the
programmers, as
is the history of legacy systems. Yes, the programmers are an
important piece of the process, but they must be managed by the
user's specifications. However, the recent trends to let the
end-users run development have been met with a fair amount of disaster, as
well.
The main problem is that end users are not typically technologically savy,
yet they have the business knowledge the developers lack. The developers
can not be left on their own to build a system, lest the end users reject
it for not solving their business problems. Also, end users and
business group managers have a very different focus than
technology managers. This leads to problems where the business
needs may not fit the technological focus of the company or where
the technological development is not fast enough for the changing
business marketplace.
Enter the Business Analyst, a technologically savy, business focused
liason.
The BA is the business side answer to the systems analyst
and today is becoming increasingly important for companies that want to
leverage their technological options in creating new business (or even
just in keeping what they currently have!).
The failure of the systems analyst was the lack of the business side
exposure when client friendly, client server products need to be
delivered. Systems analysts typically "grew up" in the technology
fields and tend to be biased towards that end. This also caused
issues of "who knows best", where technology groups were at odds with
business groups due to personal philosophies. When the end users were
internal billing and accounting
operations staff, non-friendly systems, or systems that didn't "do it all"
could still pass and make a difference. Today's clients are just too
demanding.
Analyzing business needs from the client (user) perspective and turning
them into functional specifications is a critcal time period. But those
managing these projects must have the respect of the technology
departments as well as the business groups they are working with.
For more on BA's, see a
paper on Business
Analysts by Ron Olmstead, a
leading management consultant.