Business analysis helps an organization to improve how it conducts its functions and activities in order to reduce overall costs, provide more efficient use of resources, and better support customers. It introduces the notion of process orientation, of concentrating on and rethinking end-to-end activities that create value for customers, while removing unnecessary, non-value added work. The person who carries out this task is called a business analyst or BA.

Business analysis sub-disciplines:

Business analysis, as a discipline, has a heavy overlap with requirements analysis, but focuses on identifying requirements in the context of helping organizations to achieve strategic goals through internal changes to organizational capabilities, including changes to policies, processes, and information systems.

Some professional business analysts believe that business analysis can be broken down into six major knowledge areas:

Enterprise analysis focuses on understanding the needs of the business as a whole, its strategic direction, and identifying initiatives that will allow a business to meet those strategic goals.

Requirements planning and management involves planning the requirements development process, determining which requirements are the highest priority for implementation, and managing change.

Requirements elicitation describes techniques for collecting requirements from stakeholders in a project.

Requirements analysis describes how to develop and specify requirements in enough detail to allow them to be successfully implemented by a project team.

Requirements communication describes techniques for ensuring that stakeholders have a shared understanding of the requirements and how they will be implemented.

Solution assessment and validation describes how the business analyst can verify the correctness of a proposed solution, how to support the implementation of a solution, and how to assess possible shortcomings in the implementation.

 Roles of Business Analysts:

 As the scope of business analysis is very wide, there has been a tendency for business analysts to specialize in one of the three sets of activities which constitute the scope of business analysis.

1. Strategist
Organizations need to focus on strategic matters on a more or less continuous basis in the modern business world. Business analysts, serving this need, are well-versed in analyzing the strategic profile of the organization and its environment, advising senior management on suitable policies, and the effects of policy decisions.

2. Architect
Organizations may need to introduce change to solve business problems which may have been identified by the strategic analysis, referred to above. Business analysts contribute by analyzing objectives, processes and resources, and suggesting ways by which re-design (BPR), or improvements (BPI) could be made. Particular skills of this type of analyst are "soft skills", such as knowledge of the business, requirements engineering, stakeholder analysis, and some "hard skills", such as business process modeling. Although the role requires an awareness of technology and its uses, it is not an IT-focused role.

Three elements are essential to this aspect of the business analysis effort: the redesign of core business processes; the application of enabling technologies to support the new core processes; and the management of organizational change. This aspect of business analysis is also called "business process improvement" (BPI), or "reengineering".

3. Systems analyst
There is the need to align IT Development with the systems actually running in production for the Business. A long-standing problem in business is how to get the best return from IT investments, which are generally very expensive and of critical, often strategic, importance. IT departments, aware of the problem, often create a business analyst role to better understand, and define the requirements for their IT systems. Although there may be some overlap with the developer and testing roles, the focus is always on the IT part of the change process, and generally, this type of business analyst gets involved, only when a case for change has already been made and decided upon.

In any case, the term "analyst" is lately considered somewhat misleading, insofar as analysts (i.e. problem investigators) also do design work (solution definers).

 Business process improvement:

 A business process improvement (BPI) typically involves six steps:

1. Selection of process teams and leader
Process teams, comprising 2-4 employees from various departments that are involved in the particular process, are set up. Each team selects a process team leader, typically the person who is responsible for running the respective process.

2. Process analysis training
The selected process team members are trained in process analysis and documentation techniques.

3. Process analysis interview
The members of the process teams conduct several interviews with people working along the processes. During the interview, they gather information about process structure, as well as process performance data.

4. Process documentation
The interview results are used to draw a first process map. Previously existing process descriptions are reviewed and integrated, wherever possible. Possible process improvements, discussed during the interview, are integrated into the process maps.

5. Review cycle
The draft documentation is then reviewed by the employees working in the process. Additional review cycles may be necessary in order to achieve a common view (mental image) of the process with all concerned employees. This stage is an iterative process.

6. Problem analysis
A thorough analysis of process problems can then be conducted, based on the process map, and information gathered about the process. At this time of the project, process goal information from the strategy audit is available as well, and is used to derive measures for process improvement.

Goal of business analysts:

 Ultimately, business analysts want to achieve the following outcomes:

·         Reduce waste

·         Create solutions

·         Complete projects on time

·         Improve efficiency

·         Document the right requirements

One way to assess these goals is to measure the return on investment (ROI) for all projects. Keeping score is part of human nature as we are always comparing ourselves or our performance to others, no matter what we are doing. According to Forrester Research, more than $100 billion is spent annually in the U.S. on custom and internally developed software projects. For all of these software development projects, keeping score is also important and business leaders are constantly asking for the return or ROI on a proposed project or at the conclusion of an active project. However, asking for the ROI without really understanding the underpinnings of where value is created or destroyed is putting the cart before the horse.

Reduce waste and complete projects on time

Project delays are costly in three different dimensions:

• Project costs – For every month of delay, the project team continues to rack up costs and expenses. When a large part of the development team has been outsourced, the costs will start to add up quickly and are very visible. For internal resources, the costs of delays are not as readily apparent as labor costs are essentially ‘fixed’ costs.

• Opportunity costs – Opportunity costs come in two flavors – lost revenue and unrealized expense reductions. Some projects are specifically undertaken with the purpose of driving new or additional revenues to the bottom line. For every month of delay, a company foregoes a month of this new revenue stream. The purpose of other projects is to improve efficiencies and reduce costs. Again, each month of failure postpones the realization of these expense reductions by another month. In the vast majority of cases, these opportunities are never captured or analyzed, resulting in misleading ROI calculations. Of the two opportunity costs, the lost revenue is the most egregious – and the impacts are greater and longer lasting.

N.B. On a lot of projects (particularly larger ones) the project manager is the one tasked with ensuring that a project is completed on time. The BA's job is more to ensure that if a project is not completed on time then at least the highest priority requirements are met.

Document the right requirements

Business analysts want to make sure that they define the application in a way that meets the end-users’ needs. Essentially, they want to define the right application. This means that they must document the right requirements through listening carefully to ‘customer’ feedback, and by delivering a complete set of clear requirements to the technical architects and coders who will write the program. If a business analyst has limited tools or skills to help him elicit the right requirements, then the chances are fairly high that he will end up documenting requirements that will not be used or that will need to be re-written – resulting in rework as discussed above. The time wasted to document unnecessary requirements not only impacts the business analyst, it also impacts the rest of the development cycle. Coders need to generate application code to perform these unnecessary requirements and testers need to make sure that the unwanted features actually work as documented and coded. Experts estimate that 10% to 40% of the features in new software applications are unnecessary or go unused. Being able to reduce the amount of these extra features by even one-third can result in significant savings.

Improve project efficiency

Efficiency can be achieved in two ways: by reducing rework and by shortening project length.

Rework is a common industry headache and it has become so common at many organizations that it is often built into project budgets and time lines. It generally refers to extra work needed in a project to fix errors due to incomplete or missing requirements and can impact the entire software development process from definition to coding and testing. The need for rework can be reduced by ensuring that the requirements gathering and definition processes are thorough and by ensuring that the business and technical members of a project are involved in these processes from an early stage.

Business process reengineering (BPR) is a management approach aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. The key to BPR is for organizations to look at their business processes from a "clean slate" perspective and determine how they can best construct these processes to improve how they conduct business.

Business process reengineering is also known as BPR, Business Process Redesign, Business Transformation, or Business Process Change Management.

Different definitions can be found. This section contains the definition provided in notable publications in the field.

Hammer and Champy (1993) define BPR as "... the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary measures of performance, such as cost, quality, service, and speed."

Thomas H. Davenport (1993), another well-known BPR theorist, uses the term process innovation, which he says ”encompasses the envisioning of new work strategies, the actual process design activity, and the implementation of the change in all its complex technological, human, and organizational dimensions”.

Additionally, Davenport (ibid.) points out the major difference between BPR and other approaches to organization development (OD), especially the continuous improvement or TQM movement, when he states:

"Today firms must seek not fractional, but multiplicative levels of improvement – 10x rather than 10%."

Finally, Johansson et al. (1993) provide a description of BPR relative to other process-oriented views, such as Total Quality Management (TQM) and Just-in-time (JIT), and state: "Business Process Reengineering, although a close relative, seeks radical rather than merely continuous improvement. It escalates the efforts of JIT and TQM to make process orientation a strategic tool and a core competence of the organization. BPR concentrates on core business processes, and uses the specific techniques within the JIT and TQM ”toolboxes” as enablers, while broadening the process vision."

In order to achieve the major improvements BPR is seeking for, the change of structural organizational variables, and other ways of managing and performing work is often considered as being insufficient. For being able to reap the achievable benefits fully, the use of information technology (IT) is conceived as a major contributing factor. While IT traditionally has been used for supporting the existing business functions, i.e. it was used for increasing organizational efficiency, it now plays a role as enabler of new organizational forms, and patterns of collaboration within and between organizations.

BPR derives its existence from different disciplines, and four major areas can be identified as being subjected to change in BPR - organization, technology, strategy, and people - where a process view is used as common framework for considering these dimensions. The approach can be graphically depicted by a modification of "Leavitt’s diamond" (Leavitt 1965).

Business strategy is the primary driver of BPR initiatives and the other dimensions are governed by strategy's encompassing role. The organization dimension reflects the structural elements of the company, such as hierarchical levels, the composition of organizational units, and the distribution of work between them. Technology is concerned with the use of computer systems and other forms of communication technology in the business. In BPR, information technology is generally considered as playing a role as enabler of new forms of organizing and collaborating, rather than supporting existing business functions. The people / human resources dimension deals with aspects such as education, training, motivation and reward systems. The concept of business processes - interrelated activities aiming at creating a value added output to a customer - is the basic underlying idea of BPR. These processes are characterized by a number of attributes: Process ownership, customer focus, value-adding, and cross-functionality.

The role of information technology:

 Information technology (IT) has historically played an important role in the reengineering concept. It is considered by some as a major enabler for new forms of working and collaborating within an organization and across organizational borders.

The early BPR literature, e.g. Hammer & Champy (1993), identified several so called disruptive technologies that were supposed to challenge traditional wisdom about how work should be performed.

1.      Shared databases, making information available at many places

2.      Expert systems, allowing generalists to perform specialist tasks

3.      Telecommunication networks, allowing organizations to be centralized and decentralized at the same time

4.      Decision-support tools, allowing decision-making to be a part of everybody's job

5.      Wireless data communication and portable computers, allowing field personnel to work office independent

6.      Interactive videodisk, to get in immediate contact with potential buyers

7.      Automatic identification and tracking, allowing things to tell where they are, instead of requiring to be found

8.      High performance computing, allowing on-the-fly planning and revisioning

In the mid 1990s, especially workflow management systems were considered as a significant contributor to improved process efficiency. Also ERP (Enterprise Resource Planning) vendors, such as SAP, JD Edwards, Oracle, PeopleSoft, positioned their solutions as vehicles for business process redesign and improvement.

Although there is crossover in the functionality and use of BI and business performance management solutions, there are certain areas of differentiation that seem to be consistent across the industry.

For instance, BI typically is used by taking a snapshot of transactional data and putting it in a separate database (called a data warehouse) to analyze trends and develop reports based on information captured at a given point in time. As these systems become more robust, organizations are beginning to capture data in a more timely fashion (i.e., daily or multiple times daily) to provide a more forward-looking approach to analysis.

BPM on the other hand, takes the types of data visualization tools offered within BI (i.e., reports, scorecards and dashboards), and uses them within an organization's processes. Where this is seen most is within finance, especially within budgeting, activity based costing, forecasting, consolidations, etc. Vendors develop specific interfaces within their own applications that walk users through these processes and allow collaboration across departments, centralized Web-based access, and the management of performance based on set metrics.

Sales and marketing

• The sales department can use BI to identify sales trends over time.
• Forecasts can be developed to plan and to identify sales metrics for the future.
• Sales managers can monitor and manage team performance

Operations

• BI can be used to help maintain quality control within the organization.
• Line of business (LOB) managers can use regular updates of product status to identify quality status.

Finance and accounting

• Finance and accounting teams use performance management tools to collaborate with one another, get approval from other departments, or simply follow a set of procedures to close month-end or create budgets.

Human resources (HR)

• Metrics can be set to determine performance goals and measure how employees are performing
• HR can determine if there are trends based on misuse of medical benefits, sick days taken, and whether incentive programs are having the desired effects.

Business Drivers

• By setting metrics to monitor performance, and identifying how organizations stack up against their competitors in the marketplace, organizations can capture timely information to help drive organizational performance.

In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Systematic requirements analysis is also known as requirements engineering^[1]. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).
Requirements analysis is critical to the success of a development project.
Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Main techniques:
 

 Conceptually, requirements analysis includes three types of activity:

·         Eliciting requirements: the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering.

·         Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues.

·         Recording requirements: Requirements may be documented in various forms, such as natural-language documents, use cases, user stories, or process specifications.

Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops - see below) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.

A young boy enters a barber shop and the barber whispers to his Customer,

’ This is the dumbest kid in the world. Watch while I prove it to you.’

The barber puts a dollar in one hand and 25 cents in the other,

then calls the boy over and asks, 'Which do you want, son?'

The boy takes 25 cents and leaves

'What did I tell you?' said the barber. 'That kid never learns!'

Later, when the customer leaves, he sees the same young boy coming out of the ice cream store.

'Hey, son, May I ask you a question?

Why did you take 25 cents instead of the dollar?'

The boy licked his cone and replied,

'Because the day I take the dollar, the game's over!'

.. Moral: Sometimes, when you think the other is dumb, you are making a fool of yourself.

A young boy enters a barber shop and the barber whispers to his Customer,

’ This is the dumbest kid in the world. Watch while I prove it to you.’

The barber puts a dollar in one hand and 25 cents in the other,

then calls the boy over and asks, 'Which do you want, son?'

The boy takes 25 cents and leaves

'What did I tell you?' said the barber. 'That kid never learns!'

Later, when the customer leaves, he sees the same young boy coming out of the ice cream store.

'Hey, son, May I ask you a question?

Why did you take 25 cents instead of the dollar?'

The boy licked his cone and replied,

'Because the day I take the dollar, the game's over!'

.. Moral: Sometimes, when you think the other is dumb, you are making a fool of yourself.