Analysis of Various Requests

An analyst always has just one task: to understand the existing problem or opportunity and to find the best solution to solve it or to take advantage of it. However, the analysis could be performed at various levels, and according to the type of need, it may have different forms. The analysis approach will be different if the customer wants to implement "Export customer detail to DOCX on top of the current PDF export" or if the goal is to "Implement European Union regulation on EU citizens data protection." While business analysis focuses more on strategic and tactical needs, there are also day-to-day routine problems that must be solved as well. The analyst must be able to distinguish between the various types and accordingly choose the best analysis approach.

Needs

BABOK defines business needs as "a problem or opportunity of strategic or tactical importance to be addressed." The strategic needs are targeted to reach long-term goals, they include complex decisions and are defined by senior executives. These decisions will affect the entire direction of the company. Decisions taken at this level include how to satisfy customers, how to defend against competitors, investments, mergers, acquisitions, partnerships, alliances, collaborations, etc. Examples of strategic decisions are whether to focus on a new segment of customers or which new product to introduce and when.

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

But the analysis generally, is not just about strategic decisions. Each organization also has common problems to solve. These operational needs are not complex, they are simple and routine, and they do not require sophisticated analysis since the solution is usually evident and straightforward. This category typically includes simple modifications of existing systems or operational processes.

Business Needs Analysis

Analyzing business needs means searching solution alternatives to problems or opportunities of strategic or tactical importance. The solution at this level can consist of any change to the enterprise, including changing the business process, buying a new IT system, or even introducing a new product line. At this level, the solution represents a change strategy, a high-level plan that defines how to move to the future state in which the business goals are met. The business analyst is not responsible for defining business goals, but is usually among the first to be presented with the goals and asked to find the best strategy for meeting them.

Business needs may arise from various sources:

1. There is a strategic goal that 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 underperforming process or IT system
3. Business needs may also be driven by external entities, such as customers, competition or regulator: customers want something the organization currently is not able to provide, there is a need to catch up with the competition, or new legislation must be followed

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

Before the possible solutions can be identified, all parties need to understand what is the current state of the organization; what capabilities it has at the moment. This is a prerequisite for discovering gaps which the solution is expected to fill. In our example, mapping the current state is straightforward, as currently the only way to get the parcel status information is by contacting the company directly via phone. But even in this simple scenario, the analyst needs to understand the process behind it, what 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 its understanding is crucial to successfully discover the best possible solution alternatives.

The next steps depend greatly on the selected solution. If the solution includes a custom development system, the next step is a detailed systems analysis. If the value is expected to be delivered through software provided by an external vendor, a request for proposal (RFP) is typically created, asking the potential vendors to propose their solutions. Business process analysis follows in case it has been discovered that a business process must be modified as a part of the solution. Of course, any combination of the solution components may be required, and each component could even be implemented in a separate implementation phase.

EXAMPLE

Need: "Our competitor offers to track the status of the parcels"

Analyst starts with this high-level business need and searches how to best meet it:

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

Next, in order to decide the overall approach, business goals and objectives need to be described:

• What do we really want to solve? What value do we expect to be delivered? What are the constraints, assumptions, and risks? How are we going to measure whether the solution delivered value?

Analysis has shown that the customer portal is the preferred solution despite the higher costs, so the next step is to decide how the 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 any existing solution to purchase?
• At this stage, the more concrete idea we have about the future solution, the better, however, the aim is not to create detailed solution specifications. It is sufficient to have a general idea of the change strategy and the solution.

Operational Needs Analysis

In the previous section, we introduced the category of business needs that represent high-level problems and opportunities that companies face. These needs are commonly subject to business analysis. But companies do not have only problems of strategic or tactical importance. Even more common are routine operational needs that must be solved as well.

The analysis of the operational needs is a process of seeking a solution to problems that are not of strategic or tactical importance, but despite they still require in-depth analysis. Even though these needs are not visible to senior management, it does not mean they are trivial and unimportant. The operational needs may affect a big part of the business, and it may be equally challenging to select the best solution from all solution alternatives as for the business needs. For example, stakeholders might approach the analyst with this request: "We need to improve the way the company manages document templates. The approval process must also be revised."

The request originates from the problem of having the templates spread across multiple places and using a clumsy approval process, which is based on sending statements of approving through email. The analyst needs to first understand the problem thoroughly, map the current state, find out all goals the solution must meet, and then come up with the solution alternatives. The company could develop a brand new system, it could customize an existing solution for working with documents, or it could buy some commercial solution. Each alternative must be evaluated against specific criteria, and the best solution must be selected.

Looking closer at the provided example, the similarity between analyzing operational and business needs may be spotted. Both involve the same basic steps: identify the need, select the best solution, implement the solution, verify that the solution provides value. The only difference is the context/level of abstraction at which the whole analysis process takes place. In the strategic/tactical context, the business analyst looks for a solution that could be a combination of a technical component, process component, and could even include a change to organization policies. In the operational context, the solution could also be composed of multiple components, however, it is less typical.

Solution Analysis

Not always is the analyst present in the process of defining the change strategy. The reason might be that stakeholders just want to copy the strategy implemented by the competitor, or the strategy has already been outlined by an external consultancy company. This scenario is especially typical for systems analysts who are not responsible for finding solution alternatives, but they are only expected to implement the solution which has already been selected.

This basically does not pose any problem as long as the analyst who is responsible for designing the solution first learns the business goals and objectives the solution shall satisfy. Without doing it, there is a risk that the solution will not be fully aligned with the business goals and, hence, will not provide the expected value.

Solution Components Analysis

The solution component represents any sub-part of a solution, including people, infrastructure, hardware, software, equipment, facilities, and process assets or any combination of these sub-parts. No matter the type, each component must be analyzed and described in such detail, which enables its implementation. The form of the description and level of detail depends on the component type - analysis of a business process change will certainly have a different form than analysis of a new information system. For simplicity's sake, in the rest of this chapter, we are going to assume that each solution component is always a system.

If the analyst is asked to implement a system, it is assumed that the solution component was carefully selected, and the alignment with the business goals and objectives was verified. So it is not expected from the analyst to question the value of the solution as a whole. The primary work is therefore focused mainly on the IT aspects such as functions of the system, integrations with other systems, user interface, data structures, etc. The system might be built from scratch to automate a currently manual process, or it might be a replacement of the existing system which needs upgrading, but in either case, the analyst is not expected to investigate impacts of the solution on the enterprise as this should have been done already. The analyst also does not have to verify why the system is needed and what business goals it must support as the aim of the analysis is to assess the technical feasibility and to produce inputs to the implementation.

On the other hand, there will certainly also be change requests during the project. The systems analyst must be able to verify whether the changes are in line with the purpose of the system and whether the system supports the business goals even after implementing the proposed changes (unless the business analyst is still around ready to evaluate the changes).

EXAMPLE

A software development company won a tender to deliver a customer portal for a big delivery services company whose aim is to offer customers a possibility to see the status of their parcels online. The company replied to the Request for Proposal (RFP) in which they described how they are going to implement the required features, what architecture they chose and why, how they are going to manage security, etc. Although the RFP mentioned what business problem the portal is expected to solve, the company has only a rough idea about the business goals and the strategy. But it is fine, the company is not expected to investigate whether the requested system meets the business goals, as the company is only asked to deliver the solution in the best quality possible.

However, even the software company should be a partner to its customers and should always strive to understand their business goals to show that on top of the excellent technical knowledge, they could also understand the business and provide advice in this area as well. Even though most of the work will be technical related, the team should understand the purpose and benefits of the solution they are going to build. They should also be aware that the system is part of a bigger solution and that the system aims to catch up with the main rival as it may possibly affect even some technical decisions.

System Functions Analysis

Existing systems modification, usually referred to as change requests or requests for change, include creating new or modifying existing parts of the system such as a function, user interface, data storage, or system interface.

The purpose of these requests for change is mostly to solve some immediate operational problems, aiming to make the day-to-day operations more effective. They are initiated by junior managers, team leaders, or even end-users, and they are related to a single system. They are often "invisible" for people making strategic and tactical decisions such as executives and senior managers.

Examples:

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

REMEMBER

Small change requests do not have to fulfill any strategic business problem. The goal could be just to make the work with the system more effective.

Despite the system changes do not have to have any strategic impact, it does not mean they could be implemented without analysis. These changes influence the day-to-day work of many people, indirectly impacting the performance of the whole enterprise, so each change must be well designed, and it must be ensured that it will deliver value. Even though the change is not of strategic or tactical importance, there is always some need behind it which the change is supposed to meet and that the analyst should understand to be able to outline the best possible solution.

EXAMPLE

Analyst is asked to make the following change:

"Add the customer's age on the customer detail screen"

It is a straightforward change that clearly states what the customer wants. But is it really what the customer needs? What if the real need is to "quickly find out the customer's age when the customer calls a customer support line"? Is it then still the best solution to place the client's age on the client details screen so that it is visible for everybody even though almost nobody else in the organization needs to know the age? Wouldn't it be smarter to put it on the notification dialog, which displays the basic information about the client who is calling the customer care?
Change requests are more than other requests prone to include the solution, which is the common trap that analyst must reveal in time.

Technical Requirements

Technical requirements are defined by IT people, but in many cases, they represent impacts of the requirements requested by the business. Let's assume all company's customers are stored in the Customer Relationship Management (CRM) system, and all other systems call the CRM when they need some information about a specific customer. There is also a Process Management system (PS), which includes processes. Most processes start with loading information about the customer from the CRM, which must then be manually updated by the user in the CRM in case the information is outdated. The process manager decided to replace the manual update and request the possibility to change customer details directly from the processes. From the manager's point of view, this is a change in the Process Management System. However, it also impacts the CRM, which currently does not offer a service the PS could call to change customer information remotely. Therefore, the manager's request also generates a system requirement "CRM shall expose a service for updating customer details."