Difference between revisions of "Context based ordering assistant (CBO)"

From ZUGSEIL Wiki
Jump to navigation Jump to search
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
The membership based ordering assistant allows the current user to access <u>one or more</u> procurement contexts. Each context bears a specific catalog category hierarchy with spefic product ranges. Each of these objects allow the definition of a individual procurement contexts
The '''context based ordering assistant''' allows a user to shop in <u>one or more</u> predefined procurement contexts. Contexts are made available to individual users in the [[Dev:Context definition process|context definition process]]


* '''business participant groups'''
It is part of our [[:Category:Shopping assistants|advanced guided buying tools & ordering assistants]] extension of [[ZUGSEIL Shop]].
* '''teams'''
* '''[[Dev:CBO - Projektspecific Contexts|projects]]'''
* '''workplace types'''
* '''organization units'''
{{Note|When a users enters the membership based ordering assistant mulitple context may display, if the user is member to multiple objects which permit context based ordering.}}


====== Purpose ======
Each context bears individually '''optimizied catalog category hierarchy''' and a set of specific products which target explicitly this context. This '''speeds up''' the shopping process and provides a better shopping experience.


====== Benefits ======


The '''context based ordering assistant''' is part of our [[:Category:Shopping assistants|advanced guided buying tools & ordering assistants]] extension of [[ZUGSEIL Shop]].
* '''Increased productivity''' - by reducing time for ordering products
* '''Reduction of maverick buying''' - regular users may only order predefined products, and may not purchase "out-of-scope" products
* '''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


It allows predefined stakeholders of a team specific ordering process to work together in a collaborative environment. Typical stakeholders are:
== Examples ==
*Strategic buyer
These two examples explain the value for context-based ordering
*Organization's operative buyers / lead buyers
* Operative team managers
*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====
This example is typical for personal protective equipment, which is highly regulated as it ensures the protection of staff.
*The <u>strategic buyer</u> for personal protective equipment (PPE) defines '''suppliers''' and accepts their catalogs. These catalogs are the foundation for PPE procurement.
*The organization's <u>PPE lead</u> for personal protective equipment defines '''team type/job profile specific catalogs''', predefining from which products the team managers can decide for their staff members
*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>team member</u> will only see the products made available from its team leads.


== Development articles ==
====== Transportation industry & Personal Protective Equipment ======
<u>Usecase</u>: The ordering of Personal Protective Equipment (PPE) in a large scaled public transportation company (SBB) is structured by teams, which are dedicated for specific jobs. Each of these jobs require specific equipment. Since some of these equipment are either expensive or need to be certified for the jobs, an approval process by the team managers is essential for specific processes


* [[Dev:ZUGSEIL Shop - Translations|Translations]]
<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>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.
*The <u>demand side ("Mitarbeiter")</u> will only see the products made available from its team leads.


* [[Dev:Context based ordering - Versions|Versions]]
====== 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.


* [[QA:Context based ordering - Acceptance criteria|Acceptance criteria]]
Solution: Each of the projects receives its own context. Generally this flow is adhered:


* [[QA:Context based ordering - Acceptance tests|Acceptance tests]]
* 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


== Related articles ==
== See also ==
 
* [[App:Contextbased Ordering Manager]]
* [[App:Team manager]] - To manage CBO properties on team level (upgraded to
* [[App:Project Administration]] - For managing projects and CBO properties on projects
* [[App:Facilities Administration]] - For workplace administration
* [[App:Organization units administration]] - For managing CBO properties on organization units
* [[App:Business participant groups administration]] - To manage CBO properties on BP group level
 
<u>For Developers</u>
*[[Dev:Context definition process]]
*[[Dev:Context based ordering assistant]]
*[[Dev:Context based ordering assistant]]


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

Latest revision as of 17:28, 7 December 2025

The context based ordering assistant allows a user to shop in one or more predefined procurement contexts. Contexts are made available to individual users in the context definition process

It is part of our advanced guided buying tools & ordering assistants extension of ZUGSEIL Shop.

Purpose

Each context bears individually optimizied catalog category hierarchy and a set of specific products which target explicitly this context. This speeds up the shopping process and provides a better shopping experience.

Benefits
  • Increased productivity - by reducing time for ordering products
  • Reduction of maverick buying - regular users may only order predefined products, and may not purchase "out-of-scope" products
  • 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

These two examples explain the value for context-based ordering

Transportation industry & Personal Protective Equipment

Usecase: The ordering of Personal Protective Equipment (PPE) in a large scaled public transportation company (SBB) is structured by teams, which are dedicated for specific jobs. Each of these jobs require specific equipment. Since some of these equipment are either expensive or need to be certified for the jobs, an approval process by the team managers is essential for specific processes

Solution: 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 strategic buyer 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 PPE demand leads ("Teamleiter") define team type/job profile specific products by throwing out undesired or not required products or full product categories for the team.
  • The demand side ("Mitarbeiter") will only see the products made available from its team leads.
Construction industry

Usecase: 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 demand side role ("Polier") will by default only see the products made available from its team leads

See also

For Developers