Login
The purpose of business systems analysis is to identify, analyze and specify business systems requirements for application software solutions that support users and other stakeholders of an organization. A simple framework to conceptualize this concept is visualize the value chain:
- Better requirements (complete, unambiguous, validate, delivered faster) enable...
- Better business systems (effective functionality, great customer experience, less maintenance, delivered faster) enable...
- Better business processes (organizational effectiveness and operational efficiency) that result in...
- Increased customer and business value.
Business systems application software functionality is primarily acquired via vendor product solutions or via custom build solutions. Most organizations today use (or are in the process of migrating to) vendor product solutions sometimes referred to as COTS (Commercial off-the-shelf) solutions.
Custom build solutions support functionality that is unique to an organization that cannot be supported by vendor product functionality and/or functionality that is propriety (“secret sauce”) of an organization.
There are pros/cons to each approach. However, the pros/cons are outside the scope of this post. The focus of this post is to describe the difference between system requirements for a vendor product solution and business system requirements for a custom build solution.
Business Requirements vs. Business Systems Requirements
Before going deeper into the distinction between custom build vs. vendor product business system requirements I need to make the distinction between business requirements and business systems requirements.
A business requirement is something a business needs to do (a work activity in a business process) and how the business needs to do it (policies, procedures, rules, etc.) to execute the work activity effectively and efficiently. A business system requirement specifies how a business requirement is supported by a business system solution. Business system requirements are a subset (more detailed view) of business requirements from a business system user perspective.
A simple example illustrates the distinction. Suppose that you and your team conduct business analysis of two restaurants – both are “tablecloth” style restaurants that use servers to engage customers at the tables - as opposed to fast food restaurants. One restaurant is part of a large chain (many locations, 50-100+ tables per location) and the other is a small family-owned Italian restaurant (single location, 20 tables). Based on your business analysis you find very similar business requirements (e.g., Take Reservation, Assign Reservation to Table, Take Order, Create Check, Process Payment, etc.) at both restaurants.
The question is – what is the appropriate solution to support the business requirements? The large restaurant, as part of their new Restaurant Management System (RMS) initiative, decides to support the requirement Take Reservation via RMS. The small family-owned restaurant has the same business requirement – Take Reservation. However, the small family-owned restaurant opts for a low-tech solution – capturing reservations via a manual logbook.
In other words, the same business requirement, but different solutions. The application software solution for RMS for the large restaurant requires you and your team to analyze and specify business system requirements for Take Reservation.
Custom Build vs. Vendor Product Business System Requirements
Custom build business systems requirements and associated requirement specifications are more detailed than vendor product business system requirements specifications. The specifications developed by business analysts for custom build solutions need to be sufficiently detailed to enable technical architects and software developers to design and develop (code) a solution. Business analysts need to identify, analyze, and specify all the requirements to support the solution. In other words, custom build specifications are highly detailed.
A key distinction between custom build solutions and vendor product solutions is that vendor product solutions are pre-built and provide functionality as visioned and conceived by the vendor. That said, modern vendor product solutions, especially ERP class solutions, have significant opportunities for configuring the solution to better “fit” customer specific needs.
In other words – and this is key, business analysts do not need to identify, analyze, and specify all the business system requirements associated with a vendor product solution – only the requirements for the functionality that are key/core to the organization. And the analysis and specification of this key/core functionality does not need to be as detailed as a custom build solution.
Please see the illustration below.
Business System Requirements
Custom Build vs. Vendor Product
The key/core functionality becomes part of a vendor Request for Proposal (RFP). It provides the basis for vendors to provide a bid for their vendor product solution. The key concept is that a vendor product solution is not a custom solution. Accordingly, it’s essential to focus business analysis effort on the most important functionality to develop an effective vendor RFP and to conduct fit/gap analysis as part of analyzing vendor proposals.
Also see my upcoming blog post “5 Key Components of a Vendor RFP." Subscribe to get notifications on new posts.
Next Steps
Let's start a conversation regarding your business analysis goals and objectives and how our training courses can assist in your journey.
Visit our Knowledge Hub for additional posts, whitepapers, videos, webinars, and frameworks.
Check out our business analysis training courses and our consulting solutions.
Visit my YouTube Channel
Connect with me on LinkedIn
