Context based ordering assistant (CBO) - Revision history

Stefanseiler at 17:28, 7 December 2025

2025-12-07T17:28:01Z

@@ Line 34: / Line 34: @@
 * The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads
 == See also ==
 *[[Dev:Context based ordering assistant]]
 [[Category:Shopping assistants]]

Stefanseiler: /* Construction industry */

2025-12-07T17:25:01Z

Construction industry

← Older revision		Revision as of 17:25, 7 December 2025
Line 33:		Line 33:
	* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.		* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
	* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads		* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads
	==Related apps==*[[App:Team manager]] - To manage CBO properties on team level (upgraded to
			== Related apps ==
			<nowiki>*</nowiki>[[App:Team manager]] - To manage CBO properties on team level (upgraded to
	*[[App:Business participant groups administration]] - To manage CBO properties on BP group level		*[[App:Business participant groups administration]] - To manage CBO properties on BP group level
	*[[App:Facilities Administration]] - For workplace administration		*[[App:Facilities Administration]] - For workplace administration

Stefanseiler: /* See also */

2025-12-07T17:24:38Z

Stefanseiler: /* Related articles */

2025-12-07T17:21:53Z

← Older revision		Revision as of 17:21, 7 December 2025
Line 33:		Line 33:
	* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.		* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
	* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads		* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads
	==~~= Related articles =~~==		== See also ==
	*[[Dev:Context based ordering assistant]]		*[[Dev:Context based ordering assistant]]

	[[Category:Shopping assistants]]		[[Category:Shopping assistants]]

Stefanseiler: /* Context based definition and collaboration */

2025-12-07T13:51:00Z

Context based definition and collaboration

@@ Line 12: / Line 12: @@
 * '''Procurement governance''' - For each context specific approval processes may be defined, leading to faster and more controllable purchasing processes.
 * '''Multi-Tier Purchasing Knowledge-Management''' - Each of the purchasing participants can bring its knowledge to the table and through this reduce complexity and changes for wrong purchasing decisions
 == Examples ==

Stefanseiler: /* Context defining objects */

2025-12-07T12:37:58Z

Context defining objects

@@ Line 70: / Line 70: @@
 * The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
 * The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads
+=== Related articles ===
 *[[Dev:Context based ordering assistant]]
 [[Category:Shopping assistants]]

Stefanseiler: /* Examples */

2025-12-07T12:26:10Z

Examples

← Older revision		Revision as of 12:26, 7 December 2025
Line 58:		Line 58:
	<u>Solution</u>: Each of these teams receive their own context. Cross-functional teams receive their own contexts. Staff members, which are in multiple teams are member of multiple teams, receiving their contexts. Generally this flow is adhered:		<u>Solution</u>: Each of these teams receive their own context. Cross-functional teams receive their own contexts. Staff members, which are in multiple teams are member of multiple teams, receiving their contexts. Generally this flow is adhered:
	*The <u>strategic buyer</u> for personal protective equipment (PPE) defines '''suppliers''' and manages their catalogs. Also a "internal ordering" PPE category structure with PPE specific search attributes is defined by the strategic buyers and is mapped to the relevant suppliers catalogs.		*The <u>strategic buyer</u> for personal protective equipment (PPE) defines '''suppliers''' and manages their catalogs. Also a "internal ordering" PPE category structure with PPE specific search attributes is defined by the strategic buyers and is mapped to the relevant suppliers catalogs.
	*The <u>PPE demand leads</u> define '''team type/job profile specific products''' by throwing out undesired or not required products for the team.		*The <u>PPE demand leads ("Teamleiter")</u> define '''team type/job profile specific products''' by throwing out undesired or not required products or full product categories for the team.
	*Depending on the team type / job profile the <u>team managers</u> can adopt the entire catalogs from the PPE lead and eventually add or remove individual articles from PPE lead catalogs.		*The <u>demand side ("Mitarbeiter")</u> will only see the products made available from its team leads.
	*The <u>~~team member~~</u> will only see the products made available from its team leads.

	====== Construction industry ======		====== Construction industry ======
			<u>Usecase</u>: Each construction site requires speicifc material depending on the project type. Project types are in a multi level hierachy, e.g. "Hochbau" -> "2-Familiehaus 7 Einheiten". This approach allows the definition of typical project phases and allows assignment of typically required products generally and per project phase. To avoid redundant spend and maverick buying, for specific or expensive equipment demand approval flows are required.

			Solution: Each of the projects receives its own context. Generally this flow is adhered:

			* Automatic project generation - Projects are defined in the ERP and are transmitted via an interface and classified by a project type automatically. For each of these project types a default context is defined from which the basic settings are inherited.
			* The strategic buyer at the HQ manages suppliers, categories and products. This typically happends by removing settings not suitable or not desired for this project.
			* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
			* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads

Stefanseiler: /* Context based definition and collaboration */

2025-12-07T11:55:51Z

Context based definition and collaboration

@@ Line 45: / Line 45: @@
 ====== Demand leader role ======
-This role has the same functionality as the demand side role, extended by approval functionality for demand before the purchasing process is triggered.
+This role has the same functionality as the demand side role, extended by:
@@ Line 72: / Line 88: @@
 *Team members
 Ultimately the ''context based ordering assistant'' allows team members to shop from a product sortiment, which is narrowed down to exactly the demand and organizational requirements.
-====Example for team ordering in the domain of Personal Protective Equipment====
 == Development articles ==

Stefanseiler: /* Roles in the context based ordering process */

2025-12-07T11:47:39Z

Roles in the context based ordering process

← Older revision		Revision as of 11:47, 7 December 2025
Line 13:		Line 13:
	* '''Multi-Tier Purchasing Knowledge-Management''' - Each of the purchasing participants can bring its knowledge to the table and through this reduce complexity and changes for wrong purchasing decisions		* '''Multi-Tier Purchasing Knowledge-Management''' - Each of the purchasing participants can bring its knowledge to the table and through this reduce complexity and changes for wrong purchasing decisions

	==~~= Roles in the context~~ based ~~ordering process =~~==		== Context based definition and collaboration ==
	Especially the knowledge management for the context is a central functionality for the context based ordering process to work. For optimal results, these roles work together in this way:		Especially the knowledge management for the context is a central functionality for the context based ordering process to work. For optimal results, these roles work together in this way:

Line 31:		Line 31:
	* suppliers available for preordering at predefined pickup-sites		* suppliers available for preordering at predefined pickup-sites
	* products available for internal ordering (and internal fulfillment)		* products available for internal ordering (and internal fulfillment)
	* internally available for internal ordering (and pickup at predefined pickup-sites)		* internally available for internal ordering (and pickup at predefined internal pickup-sites)

	'''Context operative manager role'''		'''Context operative manager role'''

Stefanseiler: /* General management */

2025-12-07T11:46:26Z

General management

← Older revision		Revision as of 11:46, 7 December 2025
Line 17:		Line 17:

	====== General management ======		====== General management ======
	The general management creates the context based shopping purpose once. After this is done, ~~the corresponding available contexts are managed in~~ the [[Dev:Context definition process\|context definition process]]~~. In this process, each~~ of ~~these~~ contexts ~~receives basic~~ informaiton:		The general management creates the context based shopping purpose once. After this is done, the [[Dev:Context definition process\|context definition process]] allows the creation of contexts, in which the mandatory informaiton is set:

	* generally available product groups for this product		* generally available product groups for this product
Line 23:		Line 23:
	* assigns team members and team roles		* assigns team members and team roles
	{{Note\|Typically this step is '''not''' done manually, but is rather done by interfaces, which tap into the ERP system and create contexts automatically.}}		{{Note\|Typically this step is '''not''' done manually, but is rather done by interfaces, which tap into the ERP system and create contexts automatically.}}
	~~Typically~~ the ~~context is created with <u>~~default values~~</u>~~ for ~~all other settings~~, ~~so that~~ the ~~shopping experiece does not always has to be redefined~~ from ~~zero, but requires punctual fine-tuning~~ by ~~the following~~ roles.		The [[Dev:Context definition process\|context definition process]] also allows the definition of default values for a context, which can be used in the interface process or during manual definition of a context. Still, after the context is defined, the collaboration starts from these default values by these roles.

	====== Strategic buyer role ======		====== Strategic buyer role ======

← Older revision		Revision as of 17:24, 7 December 2025
Line 33:		Line 33:
	* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.		* The demand lead role ("Bauführer/Projektmanager") fruther narrows down specific materials or categories which are not desired. The team leads can delegate the "see all products" permission to specific demand side team members.
	* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads		* The <u>demand side role ("Polier")</u> will by default only see the products made available from its team leads
			==Related apps==*[[App:Team manager]] - To manage CBO properties on team level (upgraded to
			*[[App:Business participant groups administration]] - To manage CBO properties on BP group level
			*[[App:Facilities Administration]] - For workplace administration
			*[[App:Workplace Group Administration]] - For managing CBO properties on workplace group level
			*[[App:Project Administration]] - For managing projects and CBO properties on projects
			*[[App:Organization units administration]] - For managing CBO properties on organization units
	== See also ==		== See also ==
	*[[Dev:Context based ordering assistant]]		*[[Dev:Context based ordering assistant]]

	[[Category:Shopping assistants]]		[[Category:Shopping assistants]]