Why do companies really need business systems analysts (BSA)?

It's a salient question I address with leaders and managers on a regular basis. And, if you don't know how to defend your position as a BSA, you're in a very compromising position when that big management consulting firm comes in to assess your organization's key areas of waste.

In most organizations, the value of the BSA is tacit. Your business partners have a good feeling about you; however, it's hard for them to articulate exactly how you contribute to the overall objective. And it would be nice if your developers could stand behind your value, but they're not really focused on everything you do--just on what you need them to code. Even your manager might have a hard time with your justification when questioned, possibly retorting an untenable argument like, "My developers don't have time to write requirements."

So, it's time to be explicit about what you bring to the table as a BSA. Not only will this fortify your position within the organization, but it will also help you hone your skill as a professional. Your value as a business systems analyst is to understand, explain, and communicate the requirements of the organization to the technical resources, in a way that nobody else in the organization can.


The Skill and Talent of a BSA

Although your breadth of knowledge is important, there is a real functional gap between the business and the IT resources that almost every organization has: this is where the BSA's value lies. Let's first draw the distinction between a business systems analyst (BSA) and a business analyst (BA): A BSA is usually positioned within the more technical or information management side of the organization; whereas a BA is positioned within the business units or non-IT functions (e.g., Marketing, Finance). The BSA is usually responsible for writing either the Business Requirements Document (BRD) and/or the Functional Specification (FS) on an information-related project.

Theoretically, the business is responsible for writing the BRD; however, in practice, they need the BSA's help. And theoretically the development team should be able to translate a well-crafted FS into some sort of Preliminary Design Document (PDD); however, in practice they need the BSA's help as well. One of the first things I do on an IT intervention is assess what I call translation coverage. There's usually a very long and under-appreciated knowledge path between what the business wants and what the technical developers need to know to build a proper solution. In many cases, there are gaps. Those gaps represent both a weakness and an opportunity for BSAs as therein lay the real value that they provide.


Covering the Gap

For any IT effort to succeed, it must have good translation coverage. For all but the most organizationally developed firms, trying to accomplish any IT-involved business transformation without a BSA is a fool's errand. And it's not because nobody else has the time to gather requirements--it's because BSAs have a specific talent for translating business requirements into technical specifications.

A movie-goer will tell you that the music in a suspense thriller made them feel anxious and fearful; a skilled musician will tell you that the scoring preference of minor chords over major chords is the reason why. A consumer may say they like the taste of Coke over Pepsi; a skilled taster will tell you that Coke uses more vanilla and less sweetener. BSAs have the unique ability to both understand what the business needs and explain it in terms that the technical developers understand. This is not a redundant function. In most cases, even if you sit the business person with the need next to the developer who's going to build the solution, unless there's a BSA to make the translation, there will be a critical gap in translation coverage. Nobody else in the company can do this.

The opportunity for you as a BSA is in your ability to identify a translation coverage gap and in your motivation to make sure it doesn't surface in your IT efforts. Great BSAs own the entire breadth of this knowledge transfer. Many times when I identify a translation coverage gap and there's a BSA involved, it's because the BRD, the FS, or the PDD was under-developed. It's typically not the BSA's fault--it's management's fault. That said, great BSAs look beyond management shortcomings and make it happen anyway. It may not be your job, but your value depends on how well this gap is covered. It's better to be employed than right.



A common failing of companies is an under-developed job definition for its business systems analysts--don't inherit this as your problem. In the same way you have developed the unique ability to explain business requirements to developers, I exhort you to develop a unique ability to explain your value to the company. Do this by highlighting both your breadth of knowledge (i.e. business acumen and technical expertise) and the unique gap you fill in properly translating business needs into technical solutions. If you're not advertent about your value to management, you might be inadvertently routed out of a job.