@jsiddiqui I understand that a “Business Product” is one of the standard subtypes of the Business Context factsheet too.

You could follow the modelling guidelines from LeanIX detailed here: Business Context Modeling Guidelines (leanix.net)

Generally they don’t recommend using more than 2 “dimensions” in a fact sheet for modelling, but the Business Product could be related to a Value Stream either in a Parent/Child hierarchy or the Requires/Required by method.

TAGS (great for visual cues in fact sheets) or custom Attributes can be added for additional analysis or filtering options.

I would suggest trying it out (preferably in a Sandbox) and seeing if it works for you to meet your use cases.

@Justin Swift . Thanks for responding.

I would appreciate a bit more information. If I’m understanding correctly, I can mark a business context a specific “Business Product” type. For example, I’ve created a value stream called “Process Claims”. I can mark the “type” as Business Product. That is fine, however, we have multiple products, so how can I mark the value stream to demonstrate that it is applicable to Business Product A and Business Product B, but not Business Product C? OR are you suggesting that I create individual Business Product type fact sheet and then relate them to “Value Stream” type of fact sheets? If I’m thinking wrong, then please use my example to elaborate your point of view.

Thanks again!

Hi @jsiddiqui ,

You may consider for all practical purposes that the Business Content subtypes of Business Product and Value Stream to be distinct. They are just grouped into a common Business Context fact sheet type to simplify the meta model. But because they are subtypes of the Business Context fact sheet type, the make use of default defined relations.

Both Value Stream fact sheets and Business product fact sheets may be related to Applications. Something like:

Value Stream « -- » Application « -- » Business Product

And Application may of course be related to IT Components:

Application « -- » IT Component

If you want to be able to indicate that some of Value Stream only applies to specific Business Products, you may extend the meta model to configure a relation between Value Stream and Business Product like that:

Value Stream « -- » Business Product

See https://docs-eam.leanix.net/docs/fact-sheet-relations#self-referencing-relations and https://docs-eam.leanix.net/docs/fact-sheet-relations#creating-a-conditional-relation-between-subtypes-of-the-same-fact-sheet-type for how to do that to constrain the relation to fact sheet subtypes.

Hope this helps.

@jsiddiqui This depends on how your workspace is configured but if it adheres to the standard metamodel v4 then what you are asking could look something like this. Assuming you have no “decomposition” of the value stream into lower level details steps.

Thanks @Justin Swift and @Helder.Luz . I see your responses are in the same direction and this makes sense.

One twist we have with our configuration is that we have value streams decomposed into lower level or steps, and that’s where the product differentiating “value stream steps” lie. In our example, “Process Claims” may be broken down into:

1. Claims Intake
2. Validate Member Eligibility
3. Validate Provider Eligibility
4. Validate special waivers
5. Adjudicate claim
6. Pay/deny claim

For the sake of simplicity, “Validate special waiver” may apply to business products B & C and the rest of the steps may be applicable to all products. In the solution you proposed, I can create the link between value stream step 5 and application A, not the top-level value stream “Process Claims”. The challenge will be to not be able to report the Product dependency at the top level of value stream, right?

@jsiddiqui Assuming you have made the value stream “Process Claims” the parent of the relevant lower level steps in the value stream then the standard filters and reports in LeanIX allow the roll-up to the parent level.

Particularly in the matrix style report, where you can see at the highest related level the relationships made at the lower levels. So reporting should not be a challenge if the value streams are arranged in a hierarchy.