Scp framework pdf

Steven Bleistein. A short summary of this paper. Download Download PDF. Translate PDF. Despite this, business strategy and strategic alignment issues are all but ignored in the requirements engineering research literature. B-SCP integrates the three themes of strategy, context, and process using a requirements engineering notation for each theme. We demonstrate a means of cross-referencing and integrating the notations with each other, enabling explicit traceability between business processes and business strategy.

In addition, we show a means of defining requirements problem scope as a Jackson problem diagram by applying a business modeling framework. Our approach is illustrated via application to an exemplar. The case example demonstrates the feasibility of B-SCP, and we present a comparison with other approaches.

All rights reserved. Keywords: Requirements engineering; Strategic alignment; Business strategy; Business modeling; Goal modeling; Business process modeling; Jackson problem frames 1. Effective strategic means by which a business organization competes with alignment positively influences IT effectiveness [2—4] and industry rivals [16,17]. Various aspects of business analysis leads to superior business performance [5—9]. It is thus not have been addressed in the requirements engineering research surprising that CIOs and IT executives consistently rank literature, including organizational structure and dependency alignment of IT with business strategy as a top priority [10—14].

Address: Empirical Software Engineering Research alignment. E-mail addresses: sbleistein mac. Bleistein , steven. Bleistein , karl. Cox , june. Verner , kphalp bmth. This approach combines use of business doi Bleistein et al. Goal modeling is used to represent business integrated with the other two notations in B-SCP, helping to strategy as requirements, and Jackson context diagrams [29] to verify alignment.

The strategy and The rest of this paper is organized as follows. Section 2 context parts are integrated using a problem diagram frame- provides an overview of the requirements analysis techniques work [29].

Section 3 presents the B-SCP framework. Section 6 discusses and evaluates B-SCP. Overview of goal modeling, Jackson problem diagrams, alignment with and support for business strategy, and the and role activity diagrams business processes that support that strategy. Section diagrams RADs [32] for process. A means of connecting each 2. In this paper, we extend and refine previous work 2.

Typically these goal modeling notations contain a goal model and context diagrams in order validate alignment of concrete goal, meaning a goal whose achievement or requirements with business strategy and the business processes satisfaction can be quantifiably measured, and an abstract that support that business strategy.

There are also entities used to represent activities, such as techniques. Tasks may be decomposed into sub—tasks context diagrams using a problem diagram framework by via decomposition links, and contribute to achievement of a treating goals as the requirements part of a problem diagram, a goal via a means-end contribution link. Both goals and tasks technique previously demonstrated in [27,28].

Also, as the Fig. Satisfaction of the hard goal on the left is achieved by two processes are linked to goals in the goal model. In this way, a tasks as indicated by the AND decomposition link, whereas the RAD is connected to a goal model at multiple points of hard goal on the right can be satisfied by either of the tasks, reference. Therefore, each of the three notations used is indicated by the OR decomposition link.

Simple example of a goal model structure. Overview of problem diagrams phenomena. Shared phenomena between domains are described through the following syntax: Problem frames are used to capture, structure and classify recurring software development problems with a problem b:Domain of Interest D2! Because of their focus on describing software interest in the context diagram. A problem diagram describes properties of [29].

Requirements represent the way the world is now and the way we would like constraints and references are indicated by dotted lines from the world to be. Indicative mood represents everything in the the requirements to domains of interest in the context diagram.

A requirement reference, with shared phenomena, such as activities, processes, events, states, no arrowhead such as reference cc on D3, indicates that the commands, and information. Optative mood represents the way requirement refers to some phenomena in that domain.

Context diagrams contain real world physical domain projection. Projection refers to the ability to describe domain entities called domains of interest. The phenomena that two or context according to various viewpoints, levels of abstraction, more domains of interest share are indicated by an interface and degree of detail [29].

A requirement might concern only connecting the domains of interest. Shared phenomena consist certain phenomena or certain behavior of a domain, given the of observable behavioral phenomena that occur between particular sub-problem addressed. In a different projection, the entities in a context diagram.

Context diagrams always contain other domain phenomena might be of interest to the one special domain of interest, the machine, which is a general- requirement for that particular problem. As projection is also purpose computer that is programmed. The requirements part a means of decomposing domain context into increasingly finer of a problem diagram describes the effects in the real world that degrees of detail, projection is particularly useful when the machine should guarantee. The requirements are enclosed in a dotted-line oval.

The context diagram contains several domains of interest and 2. Role activity diagrams RADs the machine. For most software problems there will be multiple requirements ovals, domain context diagrams, and numerous A role activity diagram RAD [32] is a process modeling domains of interest. A RAD is In the context diagram, the machine and three domains of used to describe business processes that can involve actions interest, D1, D2, and D3, are interconnected with solid line and interactions among roles.

Roles can be humans as well as interfaces, labeled a, b, b1, and b2, representing shared software and hardware systems. A RAD provides an excellent means of describing dependencies between roles in organiz- ations that work discretely and in unison to achieve a goal. A RAD has various components, the most common of which are illustrated in Fig. All roles start in an initial state. For example, Colleague A starts in some initial state and then an external event occurs, in this case a project has been started.

Note that an action is independent of other roles. On completion of work, Colleague A would be said to have moved to a new state of work completed. Although Fig. Anatomy of a problem diagram. Some elements of a role activity diagram. It includes both internal and external organizational structures. Where it is systems and other organizational resources, roles, entities, necessary to show an activity has been completed within a and the interactions among all of these.

This is a shared event, or interaction. Organizational goals describe only objectives the result is that both roles involved move to the state of work and intention, but say little about the context in which these delegated. While there is no sender and receiver as such, occur.

It is important to verify that goals are in alignment with Colleague A is said to initiate whereas Colleague B is passive the organizational context in which they occur, and thus the in this interaction. The initiator of an interaction is denoted by relationship between the goal model and the context diagram the hatched box and the recipient by the clear box.

Colleague B must be clear. Colleague B then returns work to notation in the requirements research community. However, Colleague A. We equate to the realization of a goal or requirement.

In addition, modeling, which we discuss later in Section 6. In addition, each process achieves a number business goal or requirements, even though a number of goal modeling notations [18,37—40] which should be made explicit [32]. They lack details of 3. The B-SCP framework for strategic alignment interaction among roles, the order in which activities are carried out, and concurrent and alternative process paths. Haglind and Cheong [43], encountering a number of Process models describe these aspects in detail and the goal obstacles in a case study of an industrial IT project, proposed that the process achieves.

However, process models describe a modeling framework for strategic alignment of enterprise neither how the goals they achieve fit into the greater objectives software architectures according to three themes, strategic of the organization or its business strategy that might be better content, business context, and business process, originally understood as a goal model. Processes also do not describe how proposed by Walsham [44].

However, Haglind and Cheong roles and resources are positioned in an organizational context provide no means of operationalization of the framework [43]. The strategy theme refers to how an organization [32], contributes to the strategic objectives of the organization intends to use IT to compete within its market or industry.

The [45]. The dashed lines depict models together. System goals and framework is to be used to verify alignment. We therefore requirements can also be validated against the objectives of use a number of techniques. Business context can be decomposed down to by treating goals as the requirements part of a problem system context using domain decomposition and projection diagram, a technique previously demonstrated in [27,28]. We [29].

RADs, with their remarkable flexibility, can model both integrate Jackson context diagrams with RADs by maintaining business and machine processes, at multiple levels of equivalence between the roles in RADs and the domains of abstraction and detail. Building a requirements model using the B-SCP in [36]. Also, as the output of a process should be the achievement of a goal In this section, we present the details of building a model for [32], processes are linked to goals in the goal model.

In this requirements analysis based on the B-SCP framework. Section way, a RAD is connected to a goal model at multiple points of 4. Section 4. This is discusses refining strategy and context in parallel from business accomplished using the goal model, as goals can be refined model level to system requirements level using a progression of from high-level strategic concerns to low-level technical ones problem diagrams. As goals are refined, they refer to presents a summary of B-SCP.

Jackson context diagrams accommodate context decomposition using projec- 4. Strategy: the goal model tion [29]. The top-level business model is which soft goals may be the norm rather than the exception and represented by the three themes of business strategy, business goal refinement is many layers deep, poses additional context, and business process.

Strategy and context are challenges for a requirements engineering goal modeler. Context and process are notations and techniques whose goal types are limited to either connected via equivalence between domains of interest and soft and hard, whose goal relationships are based on simple, roles, and between shared phenomena and interactions. Some business analysis approaches, such as that of the Business Rules Group [31], suggest that not all goals are the same when used to model business motivation or business strategy.

Task types similarly possess qualities that provide an understanding of the type of goal to which it contributes, and include mission, strategy, and tactic. The BRG-Model describes rules by which goal and task entities must relate to each other in a goal model for business Fig. The B-SCP framework. Following VMOST associated quality according to its type that provides an analysis, the BRG-Model provides a framework to guide a understanding of where it is situated in an overall model of requirements engineer in constructing a goal model.

We do not strategy and how it relates to other goals. BRG-Model tasks illustrate the process of using VMOST analysis in conjunction similarly describe not only activities and processes, but with the BRG-Model to develop a requirements engineering indicate to which type of goal in the strategic hierarchy the goal model of organizational business strategy in this paper, as process or activity is intended to achieve.

As each goal and task it is discussed in detail in [27,28]. The key is to represent what is useful and However, because the B-SCP strategy theme deals only with necessary to describe the problem being addressed. We avoid using resources, agents, and roles [18], heuristics for this [29]. However, these heuristics are useful as we prefer to represent these entities as part of context. One such tool is VMOST alternative approach to identify the problem context from standing for vision, mission, objective, strategy, tactic [30] , which to begin decomposition into sub problems.

BRG-Model, adapted from [31]. BRG-Model operationalized. Based on their definition, Fig. Please note that this is entities include the organization of interest, suppliers, allies, only a simple example for the purpose of illustration, and does customers, consumers, and the relationships among these not represent a model for a sophisticated, competitive business entities.

Each relationship describes flows of money, product, strategy. A number of key business requirements are wholesale business. The organization of interest as indicated by associated with each graphical model of business context so the double line on the left side of the entity. The wholesale that the model might be successful. These requirements outline business takes orders from customers and arranges for their the business strategy aspect of the model. While Weill and manufacture and just-in-time delivery to customers using an Vitale use this definition specifically for e-business models, the allied third-party logistics partner.

The Wholesale Business, definition is general enough to apply to any kind of business in Customer, Supplier, and Logistics Partner are described in the a value network selling any type of product or service. Note context diagram. The shared phenomena are indicated and that Weill and Vitale also propose recurring e-business models labeled with single letters, or a letter and number in the case of [35], which we do not address in this paper. The interfaces a, b, b1, b2, and c in the context for e-business in requirements analysis appears in [47].

The Weill and Vitale business model framework fits nicely The requirement part of the problem diagram describes the into a problem diagram framework, as it provides the basis for strategy of the wholesale business in the form of a goal model. The contextual 4, and O1—4. Entities in the goal model are labeled according to part of the business model, which Weill and Vitale model a convention first presented in [27] indicating BRG-Model graphically, can be modeled as a Jackson context diagram.

Similarly, S is used for Strategy and T for Tactic, participants, i. The relationships among the Fig. Requirements constraints and references are labeled participants are indicated as interfaces, whose flows of with double letters aa, bb, and cc and detailed in the box below money, products, and information are described as shared the problem diagram. In this way, we can use a problem phenomena. While Weill and Vitale simply list the strategic according to the business modeling framework suggested by requirements associated with each business model, we provide Weill and Vitale [35].

Business strategy and context as a problem diagram: wholesale business example. Who are the organization of interest, suppliers, allies, customers, and consumers in the model? These become the domains of interest and the machine in the context diagram.

What are the flows of money, product, and information, and between which participants do these flows occur? The flows represent shared phenomena, and the relationships between participants represent interfaces between domains of interest.

Progression of problems adapted from [29] p. As mentioned previously, we recommend performing this process of possible to find a requirement RC that refers only to DC while analysis by combining VMOST analysis [30] with goal satisfying RC, and so on. Through this process of domain model construction according to BRG-Model rules [31], context decomposition, analysis, problem projection, and which we do not show in this paper but demonstrate in refinement, ultimately the requirement refers just to the detail in [27,28].

As goals refer to optative properties a system is intended to Identifying the Weill and Vitale business model and ensure [51], we treat goals as requirements in problem representing it as a problem diagram with an integrated goal diagrams. Note that in Fig. A goal model representation is the critical strategic, business objectives that are to be met. It has been shown that defining project scope not only levels. For example, Fig. Lower-level requirements can thus be validated against higher-level goals, enabling validation of requirements alignment against objectives of business strategy.

Refining strategy and context At the same time, requirements can also be understood within the domain context to which they refer. The problem diagram A problem diagram at the Weill and Vitale business model framework thus also enables validation of requirements level, however, is very distant from system-level requirements, alignment within organizational context.

Bottom-up trace- and is likely to be too abstract to begin designing and ability of requirements in the goal model in conjunction with implementing a solution consisting only of hardware, software, verifying requirements within the context in which they occur data, network resources, and individual people. To refine at appropriate levels of refinement are both essential to requirements from a high-level problem diagram down to the validating overall strategic alignment of requirements.

The domain context DA represents business A process consists of tasks, activities, and roles according to context and strategy at the level of a Weill and Vitale business procedural constraints or rules in order to achieve a desired model.

Requirement RA represents the requirements of output or goal [52]. Many companies use process models to business strategy, in the form of a goal model, associated describe their activities and systems.

There is a close with the Weill and Vitale business model. Through analysis of relationship among process models, context diagrams, and DA, it is possible to decompose the domain context into a more goals. Indeed, moving from process models to context refined context diagram DB. Similarly, through analysis of DB, it problem frames has been demonstrated in [36]. In addition, is possible to decompose the domain context into context Ould recommends performing business process analysis diagram DC.

A mapping of the elements in RADs to goal models and context diagrams is described in Table 3. A role is equivalent to a domain of interest in a Jackson context diagram, but has no equivalent in a goal model consisting of goals and tasks. An action maps to a goal or task in a goal model, but has no equivalent in a context diagram. An interaction is always between two roles or among several, and thus an interaction maps directly to shared phenomena as identified by an interface in a context diagram.

An interaction also maps to a goal or task in a goal model. State descriptions map to goals in a goal model but not to tasks, and have no equivalent in context diagrams. Between RADs and Jackson context diagrams, there is a one-to-one equivalence between roles and domains of interest, and between interactions and shared phenomena.

However, the goal model cross-reference does not necessarily correspond in an exact one-to-one manner, as process models describe a degree of detail that is awkward in a goal model Fig. Wholesale business RAD. Thus, the goal model cross-reference refers to the goal entity that is closest to the activity described in the process just-in-time delivery G3, b.

The Supplier in the meantime model. The RAD in Fig. At this point, the customer has been supplied just- describes the processes of the wholesale business, and is linked in-time, achieving G1 for the Wholesale Business.

Please note for each interaction, activity, and goal appearing in the RADs, 4. B-SCP summary a cross-reference appears at the beginning of each label in parentheses. The purpose of the cross-reference of an A goal model is integrated with context diagrams via a problem interaction is to enable an analyst to situate the interaction in diagram framework [29], in a progression of problems [29] both the goal model and the context diagram in order to from the strategic-business level problem to the system level validate organizational alignment between the process model problem.

The Weill and Vitale business model framework [35] and the goal model, and between the process model and the is used to scope the strategic-level business problem diagram, a context diagram.

As mentioned above, the shared phenomenon critical step in B-SCP. RADs are connected to the goal model interface label cross-reference represents a one-to-one corre- and context diagrams by cross-referencing according to spondence.

The interaction between roles in a RAD mapping rules. The wholesale business RAD supports organizational goal 5. The Wholesale Business receives a customer order O1, a , places an order to For initial validation of a new technique, such as B-SCP, it should be applied to an appropriate requirements engineering the Supplier with the appropriate lead time G2, c , and exemplar that demonstrates its usefulness, rather than a generic arranges with the Logistics Partner for on-time pick-up and example, such as the elevator problem, the ATM problem, the Table 3 meeting scheduler, etc.

We use the case returns [55]. Our objectives in using the SEJ example are to 5. SEJ strategy: business model goals and context demonstrate 1 validation of system requirements against strategic business objectives via traceable links, and 2 cross- In this section, we present a progression of problem referencing between process models against both a goal model diagrams integrating the goals and context of the SEJ case in and context diagram as a means of better understanding the Fig.

The associated shared phenomena, requirements processes supporting business strategy. We present a partial constraints and references are detailed in Table 4. To derive view, or a projection [29] of the requirements problem, and construct the goal model in Fig. Section 5. Note that a number of goal model entities in Fig. This is to highlight the entities processes that support the strategy. The reader may find it 5. SEJ case overview useful to photocopy Fig. Note that the progression of problem diagrams includes details SEJ manages a national franchise of independently owned of multiple stakeholder concerns of the SEJ system, including convenience stores, whose Chief Executive Officer CEO the franchise storeowners, store clerks, and SEJ itself.

These business Step 1: Identify the business model participants, i. Note that while the franchise These are the business model participants that appear as stores are independently owned, SEJ is responsible for the IT of domains of interest in DA. Franchise Stores Stores in Tokyo, where land is a premium commodity, tend provide products for purchase to Consumers a.

SEJ shares to be very small, and thus have little space to stock inventory. SEJ also shares quickly, and stock must be replenished frequently. SEJ orders products from Suppliers for storeowners that addresses these requirements. To this end, SEJ delivery to stores d. The Combined Delivery Centers pick up needs to predict with precision what products consumers will product orders from Suppliers c1 and deliver product orders demand, when they will demand them, and then deliver to Franchise Stores c2.

This is particularly Step 3: Identify the strategic requirements of the business challenging for perishable goods, such as box lunches and other model and represent these as a goal model. The requirements in RA hood demographics. At odds with the need to limit inventory is reference and constrain the domains of interest in DA. SEJ the need for consumers to find what they want in the store. SEJ progression of problems: combined goal model and cotext diagrams. O1, O2 c1: Combined delivery center!

O1 c2: Combined delivery center! O1, O2 d: SEJ! T3, T4 g: SEJ host computer! T2 i: SEJ host computer! T1 DC j: Franchise store computer! T7 k1: Handheld scanner! T6 l2: Clerk! O11, T14 q: POS! T16 r: Clerk! T14, T17 r2: Clerk! Take, for example, G1 reduce lost sales unsold perishable goods G2 while guaranteeing their opportunities and lost store customer.

In theory, SEJ could freshness G5 [35]. SEJ must enable each Franchise Store achieve this simply by tracking unsatisfied customers who to stock products that consumers want when they want them leave the store without finding what they needed. However, according to continuously changing consumer needs G6 aa, bb , ensuring that the Combined Delivery Centers cc deliver Table 5 stock from Suppliers dd to stores just-in-time O1.

When a customer does not consumer profiles, neighborhood events, and local weather for find what he or she wants, he or she simply leaves. Lost sales each store T4 , updating the predictive model continuously opportunities and lost store customers cannot practically be T5 for SEJ ee.

Similarly, it may be argued that G3 maximize use of limited floor space can be 5. Domain DC and requirements set RC quantified by mathematical algorithms. To facilitate this, each store is particular product mix. However, truly achieving maximum equipped with a Franchise Store Computer. The Franchise use of limited floor space is also dependent upon getting the Store Computer shares phenomena with the Product j , to product mix right, based on store customer behavior, which as track product flow from inventory delivery intake to shelving noted above, is not entirely quantifiable.

A similar degree of and either purchase or scrapping, a Handheld Scanner k , for ambiguity also exists for the achievement of G2, G4, G5, and monitoring inventory by scanning Product barcodes k1 , used G6. For this reason, we treat G1—G6 as soft goals, even though by the Clerk particularly during reception of inventory some aspects of them may be quantifiably measurable. The DA—RA consumer purchase and profile data are collected. The context diagrams Franchise Store Computer T7.

Requirements, in the form of goal nn. A store clerk may use the GOT mm to analyze real-time model entities appearing in further problem diagrams in sales performance reports T9 and view SEJ stock order progression, will be validated against those in RA in order to recommendations T10 , and then either accept or make validate strategic alignment.

The POS oo collects consumer profile and purchase data O10 , which it regularly 5. DB represents a 5. DD describes within SEJ, serves as the machine. The POS shares phenomena Computer e for data collection and processing. The SEJ Host with the POS Cash Drawer p , which opens only after the Computer shares phenomena with a Weather Service f for clerk has entered customer profile data, the Product q , whose predictions for and records of the local weather conditions of barcode is scanned by the POS, and the Clerk r , who performs the stores, each Franchise Store g for gathering consumer the tasks of barcode scanning r1 and Consumer profiling r2.

As part of this support O3 in RA by generating stock order recommen- process, the Clerk rr is expected to take note of the dations T3 for Franchise Stores gg. SEJ Suppliers ii and shipping requests T2 to Combined Delivery relies on store clerks to enter consumer profile data, as only Centers hh , and then by maintaining up-to-date information clerks have the direct interaction with consumers necessary to on inventory in real time O7 for SEJ ee.

To forecast perform this data collection. In order to help ensure that clerks consumer demand for stores, the SEJ Host computer enter consumer profile data for each transaction O11 , the POS continuously develops a fine-grained predictive model of pp opens the Cash Drawer only after the clerk enters the data consumer purchasing behavior O6 for SEJ ee by collecting T14 [55].

We do not continue with further refinement, because to detail or notion of sequential order. To describe process aspects do so would simply be to describe a standard software of the requirements for SEJ, process modeling is helpful. Our aim is to illustrate an In this section, we examine two interrelated SEJ processes: explicit link between system requirements and the objectives of one process addresses achievement of consumer purchase and business strategy, and the processes that support business profile data and checkout, O10 of Fig.

RAD in Fig. Validating strategic alignment O3, O5 in Fig. Goals O3, O5 and O10 are shaded for your ease of reference in Fig. In In this section, we demonstrate how it is possible to validate addition, all goal model entities that are related to the process alignment with and support for strategic objectives of low-level models are outlined in bold in Fig.

The RADs in Figs. We examine two critical, strategic-level and 12 also contain roles that are equivalent and refer to the goals appearing in RA of Fig.

Interactions cross-reference both an entity goal model in Fig. The purpose of the cross- context diagrams in Fig. Validating requirements against strategy via order to validate organizational alignment between the process contribution links model and the goal model, and between the process model and In the case of the POS register, we understand the the context diagrams.

Note that the goal model cross-reference requirement T17 in which the Clerk collects the consumer does not necessarily correspond in an exact one-to-one manner. At the detail that is awkward in a goal model. The shared phenom- objectives in RA by tracing the contribution relationships up enon cross-reference, however, is a one-to-one correspon- through the goal model. The function of collecting the dence. As discussed previously in Section 4.

T12 phenomena between domains of interest in a context diagram. Collecting consumer purchase and profile data, and O6 in RB. O6 contributes to O3, then to O1, and G6, Enable Franchise stores to stock the products consumers want when the checkout process. In this O The Consumer initiates the process by presenting manner, we are able to trace how the lowest-level system products for purchase to the Clerk T15, r1.

The Clerk takes requirements align with and provide support for the strategic the Products presented for purchase T15, r1 and scans the business objectives. Achievement of T12, and then presents a total payment due to the Clerk T21, r , these is dependent upon the sub goals and tasks that contribute who informs the Consumer T21, r2.

The POS prompts the to them. It is for this reason that Fig. In this case, the POS notes that the Clerk has understanding how low-level IT systems requirements ulti- entered the required profile data, and may now continue by mately support the business strategy is so critical when opening the Cash Drawer in order to accept payment T14, p.

The token in the process, effectively satisfies O11, to ensure that the clerk enters consumer profile data for each transaction. Cross-referencing the process model While the SEJ goal model tells us much about the activities 1 The SEJ case literature does not elaborate on how age is entered, but similar and processes of the SEJ system and the context diagrams POS systems in operation today offer four or five age ranges from which the describe the context in which these occur, there is no process clerk is to select one as an approximate age.

Collecting consumer purchase and profile data, and checkout achieving O10 in Fig. The checkout process continues with the Consumer making 5. Decision support and demand forecasting process. The POS processes the payment and prints a provide stock ordering decision support, described in Fig. It the decision support and forecasting process in Fig. The POS remits customer completing the checkout task T12 and achieving O10 as purchase and profile data to the Franchise Store Computer consumer profile and purchase data has been collected.

Decision support and demand forecasting process achieving O3, O5 in Fig. The The Clerk examines the reports and recommendations SEJ Host Computer retrieves weather data associated with T9, T10, l2 , and then enters changes to the order store locations and times T4, f , correlates purchase data with recommendations, or simply accepts the recommendation consumer profile, local events, and weather T4 , and updates with no changes T11, l2 , which the GOT remits to the the consumer behavior prediction model T5, satisfying O6.

The SEJ Host Computer updates from the Weather Service T4, f , generates a stock order the order T11, achieving O3, as stock ordering decision support recommendation for stores T3 , achieving O5 as consumer has been provided. In the s, McKinsey suggested an extension that added a dynamic element to a static framework. The dynamic version suggests that the relationships among structure, conduct, and performance are not unidirectional; they flow in the opposite direction, too. This approach allows companies to consider the influence of their own conduct on an industry's structure and, ultimately, on their own performance.

Many companies use the revised model to "play through" various scenarios that might affect them, to gain an understanding of what's happening in their industries, and to develop their strategies. The seemingly timeless dynamic SCP framework is useful across regions and industries. Never miss an insight. We'll email you when new articles are published on this topic.