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.