- Business Analysis Tutorial
- Business Analysis - Home
- Business Analysis - Introduction
- Software Development Life Cycle
- Business Analysis - Roles
- Tools and Techniques
- Business Analysis - JAD Session
- Requirement Gathering Techniques
- Functional Requirements Document
- S/W Requirements Specification
- Business Analysis - Use-Cases
- Use-Case Diagrams
- Requirements Management
- Planning Good Requirements
- Business Analysis - Modelling
- Business Analysis Useful Resources
- Business Analysis - Quick Guide
- Business Analysis - Useful Resources
- Business Analysis - Discussion
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Business Analysis - Modelling
A Business Model can be defined as a representation of a business or solution that often include a graphic component along with supporting text and relationships to other components. For example, if we have to understand a company’s business model, then we would like to study the following areas like −
- Core values of the company
- What it serves?
- What is sets apart?
- Its key resources
- Major relationships
- Its delivery channels
With the help of modelling techniques, we can create a complete description of existing and proposed organizational structures, processes, and information used by the enterprise.
Business Model is a structured model, just like a blueprint for the final product to be developed. It gives structure and dynamics for planning. It also provides the foundation for the final product.
Purpose of Business Modelling
Business modelling is used to design current and future state of an enterprise. This model is used by the Business Analyst and the stakeholders to ensure that they have an accurate understanding of the current “As-Is” model of the enterprise.
It is used to verify if, stakeholders have a shared understanding of the proposed “To-be of the solution.
Analyzing requirements is a part of business modelling process and it forms the core focus area. Functional Requirements are gathered during the “Current state”. These requirements are provided by the stakeholders regarding the business processes, data, and business rules that describe the desired functionality which will be designed in the Future State.
Performing GAP Analysis
After defining the business needs, the current state (e.g. current business processes, business functions, features of a current system and services/products offered and events that the system must respond to) must be identified to understand how people, processes and technology, structure and architecture are supporting the business by seeking input from IT staff and other related stakeholders including business owners.
A gap analysis is then performed to assess, if there is any gap that prevents from achieving business needs by comparing the identified current state with the desired outcomes.
If there is no gap (i.e. the current state is adequate to meet the business needs and desired outcomes), it will probably not be necessary to launch the IT project. Otherwise, the problems/issues required to be addressed in order to bridge the gap should be identified.
Techniques such as SWOT (Strengths, Weaknesses, Opportunities and Threats) Analysis and document analysis can be used.
To Assess Proposed System
BA should assist the IT project team in assessing the proposed IT system to ensure that it meets the business needs and maximizes the values delivered to stakeholders. BA should also review the organization readiness for supporting the transition to the proposed IT system to ensure a smooth System Implementation.
BA should help the IT project team to determine whether the proposed system option and the high-level system design could meet the business needs and deliver enough business value to justify the investment. If there are more than one system options, BA should work with the IT staff to help to identify the pros and cons of each option and select the option that delivers the greatest business value.
Guiding Principles for Business Modelling
The primary role of business modelling is mostly during inception stage and elaboration stages of project and it fades during the construction and transitioning stage. It is mostly to do with analytical aspects of business combined with technical mapping of the application or software solution.
Domain and User variation − Developing a business model will frequently reveal areas of disagreement or confusion between stakeholders. The Business Analyst will need to document the following variations in the as-is model.
Multiple work units perform the same function − Document the variances in the AS-IS model. This may be different divisions or geographies.
Multiples users perform the same work − Different stakeholders may do similar work differently. The variation may be the result of different skill sets and approaches of different business units or the result of differing needs of external stakeholders serviced by the enterprise. Document the variances in the AS-IS model.
Resolution Mechanism − The Business Analyst should document whether the ToBe solution will accommodate the inconsistencies in the current business model or whether the solution will require standardization. Stakeholders need to determine which approach to follow. The To-Be model will reflect their decision.
Example of BA role in Modelling ERP Systems
A Business analyst is supposed to define a standard business process and set up into an ERP system which is of key importance for efficient implementation. It is also the duty of a BA to define the language of the developers in understandable language before the implementation and then, utilize best practices and map them based on the system capabilities.
A requirement to the system is the GAAP fit analysis, which has to balance between −
The need for the technical changes, which are the enhancements in order to achieve identity with the existing practice.
Effective changes, which are related to re-engineering of existing business processes to allow for implementation of the standard functionality and application of process models.
Functional Business Analyst
Domain expertise is generally acquired over a period by being in the “business” of doing things. For example,
A banking associate gains knowledge of various types of accounts that a customer (individual and business) can operate along with detailed business process flow.
An insurance sales representative can understand the various stages involved in procuring of an Insurance policy.
A marketing analyst has more chances of understanding the key stakeholders and business processes involved in a Customer Relationship Management system.
A Business Analyst involved in capital markets project is supposed to have subject matter expertise and strong knowledge of Equities, Fixed Income and Derivatives. Also, he is expected to have handled back office, front office, practical exposure in applying risk management models.
A Healthcare Business Analyst is required to have basic understanding of US Healthcare Financial and Utilization metrics, Technical experience and understanding of EDI 837/835/834, HIPAA guidelines, ICD codification – 9/10 and CPT codes, LOINC, SNOMED knowledge.
Some business analysts acquire domain knowledge by testing business applications and working with the business users. They create a conducive learning environment though their interpersonal and analytical skills. In some cases, they supplement their domain knowledge with a few domain certifications offered by AICPCU/IIA and LOMA in the field of Insurance and financial services. There are other institutes that offer certification in other domains.
Other Major Activities
Following a thorough examination of current business processes, you can offer highly professional assistance in identifying the optimal approach of modelling the system.
Organizing the preparation of a formalized and uniform description of business processes in a manner ensuring efficient automation in the system.
Assistance to your teams in filling out standard questionnaires for the relevant system as may be furnished by the developers.
Participation in working meetings requirements towards the developers are defined.
Check and control as to whether the requirements set by you have been properly “reproduced” and recorded in the documents describing the future model in the system (Blueprints).
Preparation of data and assisting for prototyping the system.
Assistance in preparation of data for migration of lists and balances in the format required by the system.
Review of the set-up prototype for compliance with the requirements defined by the business process owners.
Acting as a support resource to your IT teams in preparing data and actual performance of functional and integration tests in the system.
In the next section, we will discuss briefly about some of the popular Business Modelling Tools used by large organizations in IT environments.
Tool 1: Microsoft Visio
MS-Visio is a drawing and diagramming software that helps transform concepts into a visual representation. Visio provides you with pre-defined shapes, symbols, backgrounds, and borders. Just drag and drop elements into your diagram to create a professional communication tool.
Step 1 − To open a new Visio drawing, go to the Start Menu and select Programs → Visio.
Step 2 − Move your cursor over “Business Process” and select “Basic Flowchart”.
The following screenshot shows the major sections of MS-Visio application.
Let us now discuss the basic utility of each component −
A − the toolbars across the top of the screen are like other Microsoft programs such as Word and PowerPoint. If you have used these programs before, you may notice a few different functionalities, which we will explore later.
Selecting Help Diagram Gallery is a good way to become familiar with the types of drawings and diagrams that can be created in Visio.
B − The left side of the screen shows the menus specific to the type of diagram you are creating. In this case, we see −
- Arrow Shapes
- Basic Flowchart Shapes
- Borders and Titles
C − The center of the screen shows the diagram workspace, which includes the actual diagram page as well as some blank space adjacent to the page.
D − The right side of the screen shows some help functions. Some people may choose to close this window to increase the area for diagram workspace, and re-open the help functions when necessary.
Tool 2: Enterprise Architect
Enterprise architect is a visual modeling and design tool based on UML. The platform supports the design and construction of software systems, modeling business processes and modeling industry based domains. It is used by business and organizations to not only model the architecture of their systems. But to process the implementation of these models across the full application development life cycle.
The intent of Enterprise architect is to determine how an organization can most effectively achieve its current and future objectives.
Enterprise architect has four points of view which are as follows −
Business perspective − The Business perspective defines the processes and standards by which the business operates on day to day basis.
Application Perspective − The application perspective defines the interactions among the processes and standards used by the organization.
Information Perspective − This defines and classifies the raw data like document files, databases, images, presentations and spreadsheets that organization requires in order to efficiency operate.
Technology Prospective − This defines the hardware, operating systems, programming and networking solutions used by organization.
Tool 3: Rational Requisite Pro
The process of eliciting, documenting organizing tracking and changing Requirements and communicating this information across the project teams to ensure that iterative and unanticipated changes are maintained throughout the project life cycle.
Monitoring status and controlling changes to the requirement baseline. The Primary elements are Change control and Traceability.
Requisite Pro is used for the above activities and project administration purposes, the tool is used for querying and searching, Viewing the discussion that were part of the requirement.
In Requisite Pro, the user can work on the requirement document. The document is a MS-Word file created in Reqpro application and integrated with the project database. Requirements created outside Requisite pro can be imported or copied into the document.
In Requisite Pro, we can also work with traceability, here it is a dependency relationship between two requirements. Traceability is a methodical approach to managing change by linking requirements that are related to each other.
Requisite Pro makes it easy to track changes to a requirement throughout the development cycle, so it is not necessary to review all your documents individually to determine which elements need updating. You can view and manage suspect relationships using a Traceability Matrix or a Traceability Tree view.
Requisite Pro projects enable us to create a project framework in which the project artifacts are organized and managed. In each project the following are included.
- General project information
- General document information
- Document types
- Requirement types
- Requirement attributes
- Attribute values
- Cross-project traceability
Requisite Pro allows multiple user to access the same project documents and database simultaneously hence the project security aspect is to very crucial. Security prevents the system use, potential harm, or data loss from unauthorized user access to a project document.
It is recommended that the security is enabled for all RequisitePro projects. Doing so ensures that all changes to the project are associated with the proper username of the Individual who made the change, thereby ensuring that you have a complete audit trail for all changes.