In this Business Analysis training session, you will learn about Enterprise Analysis. Topics covered in this session are:
• Enterprise analysis
• SWOT Analysis
• Feasibility Evaluation
• Problem Statement & Goal Statement
• Business Case
• Project Scope Statement & Vision Document
• AS IS (current state) and TO BE (future state)
• Root Cause Analysis – Fish Bone Diagram
For more information, click here: https://www.mindsmapped.com/courses/business-analysis/business-analysis-training-for-beginners-as-per-babok-v3/
2. Page 2Classification: Restricted
Agenda
• Enterprise analysis
• SWOT Analysis
• Feasibility Evaluation
• Problem Statement & Goal Statement
• Business Case
• Project Scope Statement & Vision Document
• AS IS (current state) and TO BE (future state)
• Root Cause Analysis – Fish Bone Diagram
5. Page 5Classification: Restricted
Different Architecture
The Enterprise Architecture consists of five architectures which in total
comprise
• Business Architecture
• Information Architecture
• Application Architecture
• Technology Architecture
• Security Architecture
6. Page 6Classification: Restricted
SWOT Analysis
Strengths: characteristics of the business, or project team that give it
an advantage over others
Weaknesses (or Limitations): are characteristics that place the team at
a disadvantage relative to others
Opportunities: external chances to improve performance (e.g. make
greater profits) in the environment
Threats: external elements in the environment that could cause
trouble for the business or project.
9. Page 9Classification: Restricted
Techniques
A variety of frameworks, tools and techniques are employed to create and
maintain the Business Architecture.
The value of a framework is that it provides compartments in which to place
predefined architectural products or outputs, thus providing order and
structure to the components.
Examples of architectural frameworks include the following.
• The Zachman Framework
It is helpful to use a defined framework that provides a common structure
and classification scheme for descriptive representations of an enterprise.
One such framework that has been widely adopted by organizations both
public and private is the Zachman Framework for Enterprise Architecture
developed by John Zachman.
10. Page 10Classification: Restricted
The POLDAT Framework
Another, simpler structure that is often used in business process re-engineering
projects is the POLDAT framework. This model develops documents, tables,
matrices, graphs, models and organizes them in the following categories:
• Process – the business processes that flow value from the organization to the
customer.
• Organization – the organizational entities that operate the business
processes, including the management teams, staff positions, roles,
competencies, knowledge and skills.
11. Page 11Classification: Restricted
The POLDAT Framework
• Location – the location of the business units and other organizational
entities, e.g., call centers, distribution centers, etc.
• Data – the data and information that is the “currency” of the organization,
flowing through the processes to accomplish the business functions.
• Applications – the information technology (IT) applications that enable the
business processes to operate efficiently and provide decision-support
information to the management team.
• Technology – the enabling technology that supports the operation of the
processes and applications.
13. Page 13Classification: Restricted
Feasibility Study
• Informed Choices
• It is an analysis of the viability of an idea through a disciplined and
documented process.
• a management-oriented activity & should tell management:
• Whether the project can be done
• What are alternative solutions?
• What are the criteria for choosing among them?
• Is there a preferred alternative?
• After a feasibility study, management makes a go/no-go decision.
• A feasibility study:
• Gives focus to the project and outline alternatives
• Enhances the probability of success by addressing and mitigating factors
early on that could affect the project
• Provides quality information for decision making
• Helps to increase investment in the company
• Helps in securing funding from lending institutions and other monetary
sources
14. Page 14Classification: Restricted
Feasibility Study
• Things to be studied during the feasibility study phase:
• The present organizational system (users, policies, functions,
objectives,...)
• Problems with the present system (inconsistencies, inadequacies in
functionality, performance,...)
• Objectives and other requirements for the new system (what needs to
change?)
• Constraints, including nonfunctional requirements on the system
(preliminary pass)
• Possible alternatives (the current system [status quo] is always one of
those)
• Advantages and disadvantages of the alternatives
• Things to conclude:
• Feasibility of the project and the preferred alternative
15. Page 15Classification: Restricted
What defines feasibility study?
A feasible business venture is one where
the business will generate adequate cash flow and profits,
the business will withstand the risks it will encounter,
the business will remain viable in the long-term, and
the business will meet the goals of the founders.
16. Page 16Classification: Restricted
Sample table of content
FEASIBILITY STUDY AND ALTERNATIVES ANALYSIS
Overview
Describe the Status Quo
Define the Problems
Convert Problems to System Objectives
Identify System Constraints and Assumptions
Develop Initial Functional and Technical Requirements
Assess Project Feasibility
Identify Alternatives
Determine Risks and Effects
Determine Risks and Effects
Rank Alternatives
Ranking of proposed ranking score, criteria
Recommended solution
17. Page 17Classification: Restricted
Types of feasibility - TRELOS
T - Technology and System Feasibility
“Can it be built?”
• Technological feasibility is carried out to determine whether the company
has the capability, in terms of required technology, software, hardware,
personnel and expertise, to handle the completion of the project
R - Risk Feasibility
E - Economic Feasibility
“Will it make economic sense if it works and is built?”
“ Will it generate PROFITS?”
• Cost-based study: It is important to identify cost and benefit factors eg.
Development costs and Operational costs. This is an analysis of the costs
to be incurred in the system and the benefits derivable out of the system.
• Time-based study: This is an analysis of the time required to achieve a
return on investments. The future value of a project is also a factor.
18. Page 18Classification: Restricted
Types of feasibility - TRELOS
L – Legal Feasibility
• It includes study concerning contracts, liability, violations, and legal
other traps frequently unknown to the technical staff.
• Determines whether the proposed system conflicts with legal
requirements, e.g. a data processing system must comply with the local
Data Protection Acts.
O – Operational Feasibility
“Will it work?”
• Operational feasibility is mainly concerned with issues like whether the
system will be used if it is developed and implemented.
S – Schedule Feasibility
• A project will fail if it takes too long to be completed before it is useful.
• Schedule feasibility is a measure of how reasonable the project
timetable is.
19. Page 19Classification: Restricted
Economic feasibility
• The bottom line in many projects is economic feasibility.
• As soon as specific requirements and solutions have been identified, the analyst
can weigh the costs and benefits of each alternative. This is called a cost-benefit
analysis
• The purpose of a cost/benefit analysis is to answer questions such as:
• Is the project justified (because benefits outweigh costs)?
• Can the project be done, within given cost constraints?
• What is the minimal cost to attain a certain system?
• What is the preferred alternative, among candidate solutions?
• Examples of things to consider:
• Hardware/software selection
• How to convince management to develop the new system
• Selection among alternative financing arrangements (rent/lease/purchase)
• Difficulties -- discovering and assessing benefits and costs; they can both be
intangible, hidden and/or hard to estimate, it's also hard to rank multi-criteria
alternative
20. Page 20Classification: Restricted
Types of Benefits
• Benefits may be classified into one of the following categories:
• Monetary -- when $-values can be calculated
• Tangible (Quantified) -- when benefits can be quantified, but $-values can't be
calculated
• Intangible -- when neither of the above applies
• Examples of particular benefits:
• Cost reductions
• Error reductions
• Increased throughput
• Improved time management
How to identify benefits?
• By organizational level (operational, lower/middle/upper management)
• By department (production, purchasing, sales,...)
21. Page 21Classification: Restricted
Types of Costs
• Project-related costs
• Development and purchasing costs:
• who builds the system (internally or contracted out)?
• software used (buy or build)?
• hardware (what to buy, buy/lease)?
• facilities (site, communications, power,...)
• Installation and conversion costs:
• installing the system, training of personnel, file conversion,....
• Operational costs (on-going)
• Maintenance: hardware (maintenance, lease, materials,...), software (maintenance
fees and contracts), facilities
• Personnel: operation, maintenance
22. Page 22Classification: Restricted
Return on Investment (ROI)
• ROI is a percentage that shows what return you make by investing in
something.
ROI = (Benefit – Cost) ÷ Cost
• Example: A company invests in a project that costs $200,000. The benefit of
doing the project saves the company $230,000 in the first year alone. In this
case, the ROI = (230,000-200,000)/200,000 = 15%.
• So for ROI, Bigger is better.
23. Page 23Classification: Restricted
Operational Feasibility
The PIECES framework can help in identifying problems to be solved, and their urgency:
Performance -- Does current mode of operation provide adequate throughput and
response time?
Information -- Does current mode provide end users and managers with timely,
pertinent, accurate and usefully formatted information?
Economy -- Does current mode of operation provide cost-effective information
services to the business? Could there be a reduction in costs and/or an increase in
benefits?
Control -- Does current mode of operation offer effective controls to protect
against fraud and to guarantee accuracy and security of data and information?
Efficiency -- Does current mode of operation make maximum use of available
resources, including people, time, flow of forms,...?
Services – Does current mode of operation provide reliable service? Is it flexible and
expandable?
24. Page 24Classification: Restricted
Schedule Feasibility
• We may have the technology, but that doesn't mean we have the
skills required to properly apply that technology - The learning
curve of the team members will impact the schedule.
• Given our technical expertise, are the project deadlines
reasonable? Determine whether the deadlines are mandatory or
desirable? If the deadlines are desirable rather than mandatory,
the analyst can propose alternative schedules.
• It is preferable (unless the deadline is absolutely mandatory)
to deliver a properly functioning information system two
months late than to deliver an error-prone, useless information
system on time! Missed schedules are bad, but inadequate
systems are worse
25. Page 25Classification: Restricted
Feasibility Analysis Matrix
• How do we compare alternatives when there are multiple selection criteria
and none of the alternatives is superior across the board? - Use a Feasibility
Analysis Matrix!
• In a feasibility analysis matrix:
• The columns correspond to the candidate solutions
• Some rows correspond to the feasibility criteria
• The cells contain the feasibility assessment notes for each candidate.
• Each row can be assigned a rank or score for each criterion (e.g., for
operational feasibility, candidates can be ranked 1, 2, 3, etc.).
• After ranking or scoring all candidates on each criterion, a final ranking or
score is recorded in the last row
26. Page 26Classification: Restricted
Example of Feasibility Matrix
Feasibility Criteria Wt. Candidate 1 Candidate 2 Candidate 3
Operational Feasibility
Functionality. A description of to what degree the candidate
would benefit the organization and how well the system
would work.
Political. A description of how well received this solution
would be from both user management, user, and
organization perspective.
30%
Score: Score: Score:
Technical Feasibility
Technology. An assessment of the maturity, availability (or
ability to acquire), and desirability of the computer
technology needed to support this candidate.
Expertise. An assessment to the technical expertise needed
to develop, operate, and maintain the candidate system.
30%
Score: Score: Score:
Economic Feasibility
Cost to develop:
Payback period (discounted):
Net present value:
Detailed calculations:
30%
Score: Score: Score:
Schedule Feasibility
An assessment of how long the solution will take to design
and implement.
10%
Score: Score: Score:
Ranking: 100%
28. Page 28Classification: Restricted
What is a Problem Statement
A problem statement is a clear concise description of the issue(s) that need(s)
to be addressed by a problem solving team. It is used to center and focus the
team at the beginning, keep the team on track during the effort, and is used
to validate that the effort delivered an outcome that solves the problem
statement.
29. Page 29Classification: Restricted
Questions a Problem Statement should answer
1.What is the problem? This should explain why the team is needed.
2.Who has the problem or who is the client/customer? This should
explain who needs the solution and who will decide the problem has
been solved.
3.What form can the resolution be? What is the scope and limitations
(in time, money, resources, technologies) that can be used to solve
the problem?
31. Page 31Classification: Restricted
Example
• Provides facilities for book issue and return
• Librarian should be able to search for a book
• If the member wants a book, which is not in the library, the librarian
should be allowed to place an order for the book
• Provide security
User Requirements
A member visits the library to retum the existing book/VCD/DVD and obtain
another one. The member hands the book over to the librarian and asks tor a
particular book, based on the book/VCD/DVD title/author name/publisher
name/price/year of publication. The user may be able to locate the book from
her memory, and issue the same to the member. Alternatively, the librarian may
need to search for the book in its library database.
Problem Statement
32. Page 32Classification: Restricted
Approach
• What is the real problem we want to solve?
• What is the business justification for solving the problem?
• What are the risks associated with the issues?
• What if we do not solve the problem, or do not solve it within the dead-
• line (if a deadline is stated)?
• What are the impacts to the business for any given solution?
• Are there any constraints from the business affecting the way the problem is solved?
• Who is affected by the problem?
• Who owns the problem?
• When does the problem occur (intermittent, constant, chronic, etc.)?
• How long has the problem been going on?
• What does it look or feel like when the problem is solved (what is the vision)?
• How will we know that the problem is solved?
• Where in the organization does the problem exist?
• How do you know it is a problem?
• When did you realize it was a problem?
• What is the alignment of the problem? What business strategy, objectives, and so on is the
problem or opportunity related to?
33. Page 33Classification: Restricted
As – is : Inventory Management
Event Result
Merchandise
is needed
Physical
Inventory
Review new
Items
Place Order Received and
Reviewed by
Commercials
Designed and
produce
merchandize
Inspect and
Categorized
Merchandize
Distribute or
Transfer
Merchandise
to Stores
Merchandise
is available
to meet
customer
demand
- Head Quarter
- Commercial
- Design & Production
- Factory
- Distribution Center
- Store
- Customer
- Fashion Merchandise
- POS
- Dos
- Modem
- PDA
- Phone
- Order History
- New store opening 1 per day around the world
- Delivery is typically in 1 or 2 days after order was placed
- Zara introduce around 11,000 new items per year
- The Theorethical Inventory Systems is about 95%
accurate.
- Zero IT support is needed in most stores
Sub Process
Case for Action Vision
Obsoleted hardware and software systems
Lack of Inventory Control
Perform physical inventory frequently
No network capacity
Can’t lookup needed merchandise from other stores
May lose profit because missed order deadline
We will offer Inventory Lookup
Stores can place order online through intranet
Stores can query needed products and request store-
to-store transfer
New items display clearly on full size screen
Enhanced Order Placement process
Easy to use syste
Actors Mechanisms Metrics
34. Page 34Classification: Restricted
To-be
Event Result
Merchandise
is needed
Lookup
Inventory
Online
Review new
Items Online
Place Order
online
Received and
Reviewed by
Commercials
Designed and
produce
merchandize
Inspect and
Categorized
Merchandize
Distribute or
Transfer
Merchandise
to Stores
Merchandise
is available
to meet
customer
demand
Actors Mechanisms Metrics
- Head Quarter
- Commercial
- Design & Production
- Factory
- Distribution Center
- Store
- Customer
- Fashion Merchandise
- Intranet web-based application
- Wireless Network
- Windows-base computer
- Modem
- PDA, Dos POS
- Phone
- New store opening 1 per day around the world
- Delivery is typically in 1 or 2 days after order was placed
- Zara introduce around 11,000 new items per year
- The Integrated Inventory System provides 99% accuracy
- Zero IT support is needed in most stores- The Integrated
Inventory System provides 99% accuracy
- Reduce Order Placing and Returning time by a half
Action Taking Vision
Install a web-based Integrated Inventory System in Head Quarter
Install wireless network at each store
Install a Windows-based PC or Note Book at each store
Store will keep current POS and PDA
Configure new PC to be easily installed with a single DVD
Stick closely to the company's mission and philosophy
Increase fulfill customer demand efficiency
New system enhances current operation
Eliminate weekly physical inventory
Streamline return merchandise process
Facilitate better store-to-store
Sub Process
37. Page 37Classification: Restricted
Project Scope
Defining the proposed project scope includes:
• Describing business objectives
• Determining expected deliverables at a high level in terms of products,
services or
other outcomes
• Documenting business assumptions and constraints
• Building a statement of the anticipated work effort
38. Page 38Classification: Restricted
Project Scope
Defining the proposed project scope includes:
• Describing business objectives
• Determining expected deliverables at a high level in terms of products,
services or
other outcomes
• Documenting business assumptions and constraints
• Building a statement of the anticipated work effort
42. Page 42Classification: Restricted
Landscape of Requirements
A condition or capability needed by a
stakeholder to solve a problem or achieve an
objective.
A condition or capability that must be met or
possessed by the system or system component
to satisfy a contract, standard, specification or
other formally imposed documents .
A documented representation of a condition or
capability as in (1) or (2).
What is a Requirement?
43. Page 43Classification: Restricted
Properties of Requirements
Functionality – What the system can do.
Constraints – What the system cannot do.
Contents – What must be present in the system.
Condition - A state that must exist at a particular time.
Process - How a system provides a capability.
44. Page 44Classification: Restricted
Types of Requirements
Business Requirements are higher level requirements of the goals, objectives
or needs of the enterprise. They describe such things as the reasons why a
project is initiated, what the project will achieve, and the metrics which will be
used to measure its success. Business Requirements describe needs of the
organization as a whole, and not groups or stakeholders within it. They are
developed and defined through enterprise analysis.
User Requirements are statements of the needs of a particular stakeholder or
class of stakeholders. They describe the needs that a given stakeholder has
and how that stakeholder will interact with a solution. Stakeholder
requirements serve as a bridge between business requirements and the
various classes of solution requirements. They are developed and defined
through requirements analysis.
45. Page 45Classification: Restricted
Types of Requirements
Solution Requirements describe the characteristics of a solution that meet
business requirements and stakeholder requirements. They are developed and
defined through requirements analysis. They are frequently divided into sub-
categories:
Functional Requirements describe the behavior and information that the
solution will manage. They describe capabilities the system will be able to
perform in terms of behaviors or operations.
Non-functional Requirements capture conditions that do not directly relate
to the behavior or functionality of the solution, but rather describe
environmental conditions under which the solution must remain effective or
qualities that the systems must have. They are also known as quality or
supplementary requirements. These can include requirements related to
capacity, speed, security, availability and the information architecture and
presentation of the user interface.
46. Page 46Classification: Restricted
Types of Requirements
Transition Requirements describe capabilities that the solution must have in
order to facilitate transition from the current state of the enterprise to a
desired future state, but that will not be needed once that transition is
complete. They are differentiated from other requirements types because
they are always temporary in nature and because they cannot be developed
until both an existing and new solution are defined. They typically cover
data conversion from existing systems, skill gaps that must be addressed,
and other related changes to reach the desired future state. They are
developed and defined through solution assessment and validation.
Assumptions and Constraints identify aspects of the problem domain that
are not functional requirements of a solution and will limit or impact the
design of a solution.