Analysis of Various Requests

An analyst always has one core task: to understand an existing problem or opportunity and find the best solution to address it or capitalize on it. However, analysis can be performed at various levels, and depending on the nature of the need, it can take different forms. The analytical approach will differ significantly if a customer wants to implement "Export customer details to DOCX in addition to the current PDF export" compared to a goal like "Implement European Union regulations on EU citizens' data protection." While business analysis focuses primarily on strategic and tactical needs, there are also routine, day-to-day operational problems that must be solved. An analyst must be able to distinguish between these various types of requests and choose the best analytical approach accordingly.

Needs

BABOK defines a business need as "a problem or opportunity of strategic or tactical importance to be addressed." Strategic needs focus on achieving long-term goals, involve complex decisions, and are defined by senior executives. These decisions shape the entire direction of the company. Choices made at this level include how to satisfy customers, how to defend against competitors, as well as investments, mergers, acquisitions, partnerships, alliances, and collaborations. Examples of strategic decisions include whether to target a new customer segment or which new product to introduce and when.

Tactical needs, on the other hand, are typically identified by middle management. They are less complex and aim to deliver value in the shorter term. Improving warehouse processes, upgrading a core system, or launching a summer marketing campaign are prime examples of tactical decisions.

However, analysis in general is not just about strategic decisions. Every organization also faces routine problems that need solving. These operational needs are simple and everyday occurrences; they do not require sophisticated analysis because the solution is usually evident and straightforward. This category typically includes minor modifications to existing systems or operational processes.

Business Needs Analysis

Analyzing business needs means exploring solution alternatives for problems or opportunities of strategic or tactical importance. At this level, a solution can involve any change to the enterprise, such as modifying a business process, purchasing a new IT system, or even introducing a new product line. Here, the solution represents a change strategy—a high-level plan that defines how to transition to a future state where business goals are met. While the business analyst is not responsible for defining business goals, they are usually among the first to be presented with them and asked to find the best strategy to achieve them.

Business needs typically arise from various sources:

1. A strategic goal needs to be achieved. For example, the company wants to introduce a new product to the market.
2. The organization faces an existing problem, such as an underperforming process or IT system.
3. Business needs can be driven by external entities, such as customers, competitors, or regulators. For instance, customers might demand something the organization cannot currently provide, there may be a need to catch up with the competition, or new legislation must be complied with.

The following picture shows an example of an identified business problem, introduces two possible solutions, and highlights the preferred solution along with its components:

Before potential solutions can be identified, everyone must understand the current state of the organization and its existing capabilities. This understanding is a prerequisite for identifying the gaps that the solution is expected to fill. In our example, mapping the current state is straightforward, as the only way to get parcel status information is by contacting the company directly by phone. Yet even in this simple scenario, the analyst needs to understand the underlying process: which department is responsible for providing the information, and in which system the parcel status is stored. The as-is state always impacts the future state, and understanding it is crucial to discovering the best possible solution alternatives.

The next steps depend heavily on the selected solution. If the solution involves custom software development, the next step is a detailed systems analysis. If value is expected to be delivered through software from an external vendor, a Request for Proposal (RFP) is typically created, inviting potential vendors to propose their solutions. Business process analysis follows if it turns out that a business process must be modified as part of the solution. Of course, any combination of these solution components may be required, and each component could even be implemented in a separate phase.

EXAMPLE

Need: "Our competitor offers parcel tracking."

The analyst starts with this high-level business need and explores the best way to meet it:

• Keep the current manual process? Send just SMS/Email notifications? Create a sophisticated customer portal that could also serve other purposes in the future?

Next, to decide on the overall approach, the business goals and objectives must be defined:

• What are we really trying to solve? What value do we expect to deliver? What are the constraints, assumptions, and risks? How will we measure whether the solution actually delivered value?

Analysis shows that a customer portal is the preferred solution despite higher costs. The next step is to decide how that solution will be delivered:

• Are we going to build it in-house, or is it better to find a software vendor to implement it for us? Is there an existing commercial solution we can purchase?
• At this stage, the more concrete our idea of the future solution, the better. However, the aim is not to create detailed technical specifications yet. It is enough to have a general idea of the change strategy and the overall solution.

Operational Needs Analysis

In the previous section, we introduced business needs, which represent high-level problems and opportunities that companies face. These needs are the typical focus of business analysis. However, companies do not only deal with problems of strategic or tactical importance. Routine operational needs that require resolution are even more common.

Analyzing operational needs involves finding solutions to problems that lack strategic or tactical weight but still require in-depth analysis. Just because these needs aren't on senior management's radar doesn't mean they are trivial or unimportant. Operational needs can affect a large part of the business, and selecting the best option from various solution alternatives can be just as challenging as it is for major business needs. For example, stakeholders might approach an analyst with this request: "We need to improve how the company manages document templates. The approval process also needs to be revised."

This request stems from the problem of templates being scattered across multiple locations and a clumsy approval process relies on sending approval statements back and forth via email. The analyst must first thoroughly understand the problem, map the current state, identify all the goals the solution must meet, and then propose alternative solutions. The company could develop a brand-new system, customize an existing document management tool, or buy a commercial solution. Each alternative must be evaluated against specific criteria to select the best path forward.

Looking closely at this example, you can see clear similarities between analyzing operational needs and business needs. Both involve the same fundamental steps: identify the need, select the best solution, implement it, and verify that it delivers value. The only difference is the context and level of abstraction at which the analysis takes place. In a strategic or tactical context, a business analyst looks for a solution that might combine technical and process components, and could even include changes to organizational policies. In an operational context, a solution can also consist of multiple components, though this is less common.

Solution Analysis

An analyst is not always involved in defining the change strategy. This might happen because stakeholders simply want to copy a competitor's strategy, or because the strategy has already been outlined by an external consultancy. This scenario is especially typical for systems analysts, who are not responsible for finding alternative solutions but are instead expected to implement a solution that has already been selected.

This does not pose a problem as long as the analyst responsible for designing the solution first understands the business goals and objectives it is meant to satisfy. Without doing so, there is a risk that the solution will not align with business goals and will fail to deliver the expected value.

Solution Components Analysis

A solution component represents any sub-part of a solution, including people, infrastructure, hardware, software, equipment, facilities, process assets, or any combination thereof. Regardless of its type, each component must be analyzed and described in enough detail to allow for its implementation. The form of this description and the level of detail depend on the component type—analyzing a business process change will look entirely different from analyzing a new information system. For simplicity's sake, we will assume for the rest of this chapter that each solution component is a system.

When an analyst is asked to implement a system, it is assumed that the solution component was carefully selected and its alignment with business goals was verified. Therefore, the analyst is not expected to question the value of the solution as a whole. The primary focus is on IT aspects, such as system functionality, integrations, user interfaces, data structures, etc. The system might be built from scratch to automate a currently manual process, or it might replace an existing system that needs an upgrade. In either case, the analyst does not need to investigate the solution's impact on the wider enterprise, as this should have already been addressed. The analyst also does not have to verify why the system is needed or what business goals it supports; the aim of the analysis is simply to assess technical feasibility and produce inputs for implementation.

On the other hand, change requests will inevitably arise during the project. The systems analyst must be able to verify whether these changes align with the system's purpose and ensure that the system continues to support business goals after the proposed changes are implemented (unless a business analyst is still around to evaluate them).

EXAMPLE

A software development company wins a tender to deliver a customer portal for a large delivery services company that wants to offer customers the ability to track their parcel status online. The development company responded to a Request for Proposal (RFP) by describing how they would implement the required features, the architecture they chose and why, how they would manage security, etc. Although the RFP mentioned the business problem the portal is expected to solve, the development company only has a rough idea of the broader business goals and strategy. But that is fine; they are not expected to investigate whether the requested system meets those business goals, as they were simply hired to deliver the solution in the best possible quality.

However, even a software company should act as a partner to its customers. They should always strive to understand the underlying business goals to demonstrate that, in addition to excellent technical knowledge, they understand the business and can provide valuable advice. Even though most of the work will be technical, the team should understand the purpose and benefits of what they are building. They should also be aware that the system is part of a larger solution aimed at catching up with a key rival, as this context could influence technical decisions.

System Functions Analysis

Modifications to existing systems—usually referred to as change requests or requests for change—include creating new components or modifying existing parts of a system, such as functions, user interfaces, data storage, or system interfaces.

The purpose of these change requests is usually to solve immediate operational problems and make day-to-day operations more efficient. They are typically initiated by junior managers, team leaders, or end-users, and relate to a single system. These requests are often "invisible" to executives and senior managers who make strategic and tactical decisions.

Examples:

• "If a user does not have the ABC role, function XYZ should be unavailable."
• "We need to be able to change a customer's age."

REMEMBER

Small change requests do not need to satisfy a strategic business goal. The objective might simply be to make working with the system more efficient.

Even though system changes may not have a strategic impact, they cannot be implemented without prior analysis. These changes influence the day-to-day work of many people and indirectly impact the performance of the entire enterprise. Therefore, each change must be well-designed and guaranteed to deliver value. Even if a change isn't of strategic or tactical importance, there is always an underlying need that it