Product Mix Analysis, Customer Requirement Analysis

A market analysis studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and thus in turn of the global environmental analysis. Through all of these analyses, the strengths, weaknesses, opportunities and threats (SWOT) of a company can be identified. Finally, with the help of a SWOT analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm’s planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company.

Product Mix Analysis

Product mix, also known as product assortment or product portfolio, refers to the complete set of products and/or services offered by a firm. A product mix consists of product lines, which are associated items that consumers tend to use together or think of as similar products or services.

The principle of product mix analysis, as described in all these texts is, in fact, correct and essential. The appeal of product mix analysis results from its simple yet powerful application, providing a platform to base the search for higher profitability and production throughputs. After years of practicing OR and quantitative methods in industry, however, I have come to the realization that an effective application of product mix analysis is not nearly as simple as illustrated in these texts. I will therefore outline the necessary steps, challenges and possible pitfalls of a practical application of product mix analysis to improve the profitability of an operation or business.

Product mix analysis is not as simple as it looks. In a typical textbook illustration of a product mix problem, a company produces several products, each requiring a certain amount of labor and materials. Constraints, such as total amount of resources and the maximum number of units that each product can sell, as well as the unit profit for each product, are given. The analysis focuses on how many products to produce in order to maximize the overall profit, correctly illustrating the essence of the product mix problem. However, the case does not even begin to reveal the complexities of a real and practical product mix study commonly used in industry.

First, the data needed for product mix study does not come in a handy form that is ready to import by an OR/MS practitioner into a spreadsheet for quick analysis. Obtaining and formatting the necessary information for analysis requires at least a few days and up to several months, depending upon the scope, complexity and purpose of the analysis.

After the first hurdle in data requirements is crossed and initial analysis of the product mix is conducted, a practitioner will usually be faced with the next issue: Is the current “optimized” product mix truly the best? In practical applications, the product mix study is rarely a one-shot deal, taking time and effort. Analysis is iterative, each iteration representing one of numerous different businesses and/or production scenarios.

The third difficulty of product mix analysis is its implementation. Even after an “optimal” product mix is found, the realization of the product mix within the operation is a challenge. An optimized product mix usually represents an idealized and somewhat macro view of the production profile, delivering a profit obtained in the analysis. In many cases, however, operational constraints in production and in the supply chain that were not or cannot be specifically formulated into the product mix optimization such as availability of raw materials, seasonality of customer demand and bottlenecks of equipment and resources may deem your product mix results infeasible.

Your product mix shapes your brand image and the customers you attract

Your product mix helps create customers’ perception of your brand. For example, if Neiman Marcus had many bargain brands in their product mix, they would likely lose their reputation as a luxury retailer. Clients looking for luxury goods would go elsewhere, and the company would, instead, be competing with retailers like Kohls.

Your product mix makes it easy for customers to buy

 Knowing your customers and nailing the right product mix is more important than ever in the age of online shopping. Customers come with precise demands and expectations, and they can easily pull up a new tab and load your competition’s website. Tailoring your product mix to your customers’ needs and desires will help you retain them.

Your product mix must help mitigate the paradox of choice

Plenty of studies have demonstrated the paradox of choice: Customers insist on a range of choice and variety, but too many options will cause them to move on without making a decision. In one study, a display of 24 jams and jellies was put out on a store floor. While it attracted shoppers, only 3% converted. The next week, a display of only six jams and jellies was created. That display drew fewer shoppers, but 30% converted.

Customer Requirement Analysis

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.

Requirements analysis is critical to the success or failure of a systems or software project. The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Conceptually, requirements analysis includes three types of activities:

• Eliciting requirements: (e.g. the project charter or definition), business process documentation, and stakeholder interviews. This is sometimes also called requirements gathering or requirements discovery.
• Recording requirements: Requirements may be documented in various forms, usually including a summary list and may include natural-language documents, use cases, user stories, process specifications and a variety of models including data models.
• Analyzing requirements: Determining whether the stated requirements are clear, complete, unduplicated, concise, valid, consistent and unambiguous, and resolving any apparent conflicts. Analyzing can also include sizing requirements.

Stakeholder identification

See Stakeholder analysis for a discussion of people or organizations (legal entities such as companies, standards bodies) that have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:

• Anyone who operates the system (normal and maintenance operators)
• Anyone who benefits from the system (functional, political, financial and social beneficiaries)
• Anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product.
• Organizations which regulate aspects of the system (financial, safety, and other regulators)
• People or organizations opposed to the system (negative stakeholders; see also misuse case)
• Organizations responsible for systems which interface with the system under design.
• Those organizations who integrate horizontally with the organization for whom the analyst is designing the system.

Joint Requirements Development (JRD) Sessions

Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator (Business Analyst), wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe should be present to document the discussion, freeing up the Business Analyst to lead the discussion in a direction that generates appropriate requirements which meet the session objective.

JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements.

Contract-style requirement lists

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages long.

An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day.

Strengths

• Provides a checklist of requirements.
• Provide a contract between the project sponsors and developers.
• For a large system can provide a high level description from which lower-level requirements can be derived.

Weaknesses

• Such lists can run to hundreds of pages. They are not intended to serve as a reader-friendly description of the desired application.
• Such requirements lists abstract all the requirements and so there is little context. The Business Analyst may include context for requirements in accompanying design documentation.

Types of Requirements

Business requirements

Statements of business level goals, without reference to detailed functionality. These are usually high level (software and/or hardware) capabilities that are needed to achieve a business outcome.

Customer requirements

Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing:

• Operational distribution or deployment: Where will the system be used?
• Mission profile or scenario: How will the system accomplish its mission objective?
• Performance and related parameters: What are the critical system parameters to accomplish the mission?
• Utilization environments: How are the various system components to be used?
• Effectiveness requirements: How effective or efficient must the system be in performing its mission?
• Operational life cycle: How long will the system be in use by the user?
• Environment: What environments will the system be expected to operate in an effective manner?

Architectural requirements

Architectural requirements explain what has to be done by identifying the necessary systems architecture of a system.

Structural requirements

Structural requirements explain what has to be done by identifying the necessary structure of a system.

Behavioral requirements

Behavioral requirements explain what has to be done by identifying the necessary behavior of a system.

Functional requirements

Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.

Non-functional requirements

Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.

Performance requirements

The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.

Design requirements

The “build to”, “code to”, and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.

Derived requirements

Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.

Allocated requirements

A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.