Difference between revisions of "Basic structure of this wiki"

From ZUGSEIL Wiki
Jump to navigation Jump to search
 
(26 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[File:Wiki-Structure.png|thumb|700px|Basic ZUGSEIL wiki structure]]The '''Start/Main Page''' presents the user an overview of all content and refers to the product pages. From there the user can navigate to various '''General Pages''' (like this one) which provide information on ZUGSEIL or the ZUGSEIL products.
This wiki aims to be an information and collaborative knowledge-management base for all stakeholders of the ZUGSEIL Team and its users.  


== Product Pages ==
To clarify the structure of the wiki we have built that chart where each page can clearly be assigned to one page-class. Each page class is member of its own pageclass-category. Here is the list of available page classes:
Each product offered by ZUGSEIL has its own '''Product Page''', which is category page of all [[bop service bundles]] offered by ZUGSEIL as part of the product described in this page. In the content section of the category page, more information on the product is provided:  


* a description of the product
== General Pages ==
 
[[File:Wiki-Structure.png|thumb|550px|Basic ZUGSEIL wiki structure]]The '''Start/Main Page''' presents the user an overview of all content and refers to the product pages. From there the user can navigate to various '''General Pages''' (like this one) which provide information on [https://www.zugseil.com ZUGSEIL] or the [https://www.zugseil.com ZUGSEIL] products.
* the target audiences of the product
 
* a list of all sales features each linking to a ''sales feature page''.  “sales” means that only features are listed here worth mentioning to the customer. If a user of the wiki wants to find a full overview on what services are part of the product, he has to browse over the service bundle pages with their contained services.  
*Similar products and feature comparison.
The Product Pages are maintained by the Sales Team. The target audience for the product page are managers of potential customers, which seek information on our products.


== Product Pages ==
Each product offered by ZUGSEIL has its own '''Product Page.'''  You can read up on the recommended structure and contents of a Product Page in [[Dev:Recommended structure of a Product Page|this article]]. Each product page serves a category page of all [[Service Bundle|b-op service bundles]] which are deployable as part of the product described in this page. Each product page is member of the [[:Category:Products|Products Category]]. The primary maintainers of Product Pages are the Sales Team.
== Service Bundle Pages ==
== Service Bundle Pages ==


*
A [[Digital|b-op digital]] may subscribe to Products. Each of these Products consist of one or more [[Service Bundle|b-op service bundles]]. Each service bundle has its own '''Service Bundle Page.''' You can read up on the recommended structure and contents of a Service Bundle Page in [[Dev:Recommended structure of a Service Bunde Page|this article]]'''.''' Each Service Bundle Page serves as Category Page for the '''Service Info&Help Pages''' of the [[Service|b-op services]] deployable as part of the [[Service Bundle|service bundle]]. The ''primary maintainers of the Service Bundle Pages are'' the Product Management Team. 


Products to which a b-op digital may subscribe consist of b-op service bundles. Their purpose is to simplify the installation of the product or parts of it, so that the b-op digital does not have to install services one-by-one but as a bundle. A service bundle typically consists of services which are closely connected or have a hard dependency.  
== Service Info&Help Page ==
The '''Service Info&Help Pages''' provide various information on a specific service. Each released service version has its own '''Service Info&Help Page'''. You can read up on the recommended structure and contents of a Service Info&Help Page in [[Dev:Recommended structure of a Service Info&Help Page|this article]]. The primary maintainers of these pages are the Q&A Team during the tests of the acceptance of the service.  


The '''Service Bundle Page''' contains a description of the service bundle. Each Service Bundle Page also serves as Category Page for the Service Pages of the services in the bundle.


The ''Service Bundle Pages'' are maintained by the Product Management Team. The target audience for the ''Software Feature Pages'' are DevOps and Project Managers which implement b-op based applications for customers.
== Business Epic Pages ==
== Business Epic Pages ==
A '''Business Epic Page''' contains a description of an area of business from a customer`s perspective. It is mostly meant to be a advertising text describing problems in this business area and puts the software features our products offer in this area in a context of the entire area and links their ''Software Feature pages.''
A '''Business Epic Page''' contains a description of an area of business.


An epic page is typically structured with these content-sections:
The target audience for the business Epic pages are:
* potential customers, which seek information on our products
* developers which need basic understanding on the area of business they are developing software for
An ''Business Epic Page'' is typically structured with these content-sections:
* '''Business Area''' - a general description of the business area and its specific requirements.
* '''Challenges -''' descriptions of problems in this area and how these problems are solved by our ''Software Features'' (each with links to Sales Feature Pages)
All this should be described from a customer`s perspective, so that the customer understands what issues will be resolved by ZUGSEIL products.


* general description of the business area
The Product Pages are maintained by the Product Management Team.
* descriptions of problems in this area and how these problems are solved by our ''Software Features'' (each with links to Software Feature Pages)


Each '''Business Epic Page''' also serves as Category Page for all Business Processes covered by our Features.
Examples for Business Epics are ''Internal Ordering, Sourcing & Procurement, Warehousing, Fulfillment''


The Product Pages are maintained by the Product Management Team. The target audience for the business Epic pages are:
== Sales Feature Pages ==
Each feature enabled by a product has its own '''Sales Feature Page'''. A ''Software Feature'' is a set of functionality, which is defined by one or multiple business processes it covers. 


* potential customers, which seek information on our products
The target audience for the ''Software Feature Pages'' are: 
* developers which need an overview on the area of business they are developing software for
Examples for Business Epics are ''Internal Ordering, Sourcing & Procurement, Warehousing, Fulfillment''


== Software Feature Pages ==
* potential customers, which seek further information on our products
Each feature enabled by a product has its own '''Software''' '''Feature Page'''. A ''Software Feature'' is a set of functionality, which is defined by one or multiple business processes it covers. The page focuses on the business case and value it provides (savings, automation level, ...) but <u>not</u> on the business processes on a detailed level.   
* developers which need an a business perspective on the business on the service they are developing for
As a result the page focuses on the business case and value it provides (savings, automation level, ...) but <u>not</u> on the business processes on a detailed level, which are described in the ''Business Process Pages.''  


Each of these ''Feature Pages'' typically contains:   
Each of these ''Feature Pages'' typically contains these content-sections:   


* a general description of the business case the feature is enabling together with high level business process chains affected by the software feature
* '''Feature description''' - a general description of the business case the feature is enabling together with high level business process chains affected by the software feature


* a business value description for the customer ("What value does it deliver for me?")
* '''Business value''' - a business value description for the customer ("What value does it deliver for me?")


* a list of all business processes required for delivering ''Software Feature (''without description, but with a link to the dedicated ''business process page'').
* '''Business Processes''' - A text on business processes which are affected by feature ''(''please provide links to the dedicated ''business process pages'').
Each '''Software''' '''Feature Page''' also serves as Category Page for the User Journeys possible by this ''Software Feature and may as well have subpages.''
Each '''Software''' '''Feature Page''' also serves as Category Page for the User Journeys enabled by this ''Software Sales Feature.''  


The Product Pages are maintained by the Product Management Team. The target audience for the ''Software Feature Pages'' are:
The Product Pages are maintained by the Product Management Team.  


* potential customers, which seek further information on our products
Examples for a Feature is ''Regular Internal Ordering.''
* developers which need an a business perspective on the business on the service they are developing for
Examples for a Feature are ''Regular Internal Ordering or Laundry Site Services.''


== Business Process Pages ==
== Business Process Pages ==
A '''Business Process Page''' provides a detailed description of a business process from its start to its end. They are closely linked to ''User Journey Pages'', but describe the business process in an abstract <u>business process engineering</u> manner.
A '''Business Process Page''' provides a detailed description of a business process from its start to its end. They are closely linked to ''User Journey Pages'', but describe the business process in an abstract <u>business process engineering</u> manner.


The ''Business Process Page'' contains information on:
The ''Business Process Page'' contains these sections:


* a ''reference workflow'' of this business process (without providing screenshots). This description should be linked to ''User Journey Pages'' to enable the user how the coverage of this business process will look alike when he is using our software.
* '''Reference workflow -''' a ''reference workflow'' of this business process (without providing screenshots). This description should be linked to ''User Journey Pages'' to enable the user how the coverage of this business process will look alike when he is using our software.
* a description of each step of the entire process. This description should be linked to ''User Help Pages'', where individual pages are explained.
* '''Step by step''' - a description of each step of the entire process. This description should be linked to ''Service Pages'' and ''Service Help Pages'', where the service is are explained. In the case that a step is a subprocess, please create another ''Business Process Page'' for this subprocess, which is liked from the initial page.
* possible variations of the process and reference to all ''software features'' which require this business process to operate.
* '''Variations -''' possible variations of the process and reference to all ''software features'' which require this business process to operate.


The information should be not from the technical view but rather from the business and user perspective so that a person reading this page understands which value can be generated from our software to his processes.
The information should be not from the technical view but rather from the business analysts view, so that a person reading this page understands which value can be generated from our software to his processes.


Examples for Business Process Pages are:
* Assisted Ordering for a team member
* Laundry Bring-In at a Laundry-Shop
The Product Pages are the main place for knowhow on our software. When development is planned the initial description is created by product or project management. When the initial creation process is covered, typically development management and support management contribute more to these articles. The target audience for the business process pages are:
The Product Pages are the main place for knowhow on our software. When development is planned the initial description is created by product or project management. When the initial creation process is covered, typically development management and support management contribute more to these articles. The target audience for the business process pages are:


Line 75: Line 69:
*project managers in training, which need to refresh or build their knowledge on how everything is connected in a business process
*project managers in training, which need to refresh or build their knowledge on how everything is connected in a business process
* developers which need a full <u>detailed view on the entire business process and its known variations</u> for the development process.
* developers which need a full <u>detailed view on the entire business process and its known variations</u> for the development process.
 
Examples for Business Process Pages are:
* Assisted Ordering for a team member
* Laundry Bring-In at a Laundry-Shop
== User Journey Pages ==
== User Journey Pages ==
Each task the user wants to complete should have User Journey Page. The name of a '''User Journey Page''' typically starts with "''How can I ...'' ". Each user journey page also is a category page, to which all ''Service Help Pages'' are linked which the user needs to visit, operate or use during the described user journey.
Each task the user wants to complete should have User Journey Page. The name of a '''User Journey Page''' typically starts with "''How can I ...'' ". Each user journey page also is a category page, to which all ''Service Help Pages'' are linked which the user needs to visit, operate or use during the described user journey.
Line 92: Line 88:


== Service Pages ==
== Service Pages ==
The '''Service Page''' provides low level information on a service. It is initially created by the project manager by providing a service name and a service-uid
For each [[b-op service]] developed by ZUGSEIL a '''Service Page''' is created by the manager responsible for specification for the development of the service. '''The target audience for the content of the service page are developers which should receive all information to implement this specific service. The service page is in the "Dev"-namespace which is only accessible to wiki-users having the permission to view the contents of this namespace.'''
 
* A header section, marked by <nowiki><nowiki bop="basicServiceInfo"/></nowiki>. It contains generic information like service-type, Service-veservice-description,
* The first section holds information on what the user can achieve with it. This part is Also it holds the configuration options and an explanation of these
* The configuration section
*
* The release history section
* The compatibility section, which is autogenerated


Available types are:
As a lot of content is created from the b-op Service Descriptor by development automatically, it is <u>essential</u> for the creating manager to perform these steps:


* App - Full window applications
* add into the wiki-source page a reference to the service-uid by adding this content in the page in this form:  '''<nowiki><nowiki bop="ServicePage" serviceID="{service-UID}" /></nowiki>'''
* Dashboard widget - Apps which can be placed
* make this page member of the category Servicepages by adding this line to the wiki-source page:  '''<nowiki>[[Category:Service Pages]]</nowiki>'''
* Configuration options
== Service Help Page ==


After this is done, the responsbile manager structures the content in these sections (each on Heading-Level):


* '''Purpose -''' What the user can achieve with it?
*'''Business Background''' - references to the business process pages which are relevant to this service
* '''Layout''' - A description on "How does it look like?" (e.g. Mockups, Drawings, ... )
* '''Functionality''' - A description "What should happen?" (foreground and background)
*'''Acceptance Criteria''' - A description on what the QA-Team should look on.  ("The tests planned for acceptance")


It is considered good practice to link as many other articles as possible to support developers and testers to produce as much quality output as possible.


Upon and during the development-phase the b-op wiki-page generators will then automatically:


* append a "version-history" section containing a table of all versions and their states (planned, development started, in testing, publicly available)
* creates the initial version of a ''Service Help Page'', which is then populated by the Q&A team during the testing phase and by the support team after the golive.
* create these subpages for each version
**development history page, where developers can document important questions. The reponsible manager can then further clarify in the service page.
**The configuration subpage, which contains all configuration options as defined in the b-op service descriptor
**The dependency subpage, which contains the information of the b-op service descriptor in a human readable way
**The compatibility subpage, which contains the information of the b-op service descriptor in a human readable way
**The q&a test subpage, containing relevant information of the q&a process of this service


User Help Pages
__NOTOC__

Latest revision as of 09:19, 27 July 2023

This wiki aims to be an information and collaborative knowledge-management base for all stakeholders of the ZUGSEIL Team and its users.

To clarify the structure of the wiki we have built that chart where each page can clearly be assigned to one page-class. Each page class is member of its own pageclass-category. Here is the list of available page classes:

General Pages

Basic ZUGSEIL wiki structure

The Start/Main Page presents the user an overview of all content and refers to the product pages. From there the user can navigate to various General Pages (like this one) which provide information on ZUGSEIL or the ZUGSEIL products.

Product Pages

Each product offered by ZUGSEIL has its own Product Page. You can read up on the recommended structure and contents of a Product Page in this article. Each product page serves a category page of all b-op service bundles which are deployable as part of the product described in this page. Each product page is member of the Products Category. The primary maintainers of Product Pages are the Sales Team.

Service Bundle Pages

A b-op digital may subscribe to Products. Each of these Products consist of one or more b-op service bundles. Each service bundle has its own Service Bundle Page. You can read up on the recommended structure and contents of a Service Bundle Page in this article. Each Service Bundle Page serves as Category Page for the Service Info&Help Pages of the b-op services deployable as part of the service bundle. The primary maintainers of the Service Bundle Pages are the Product Management Team.

Service Info&Help Page

The Service Info&Help Pages provide various information on a specific service. Each released service version has its own Service Info&Help Page. You can read up on the recommended structure and contents of a Service Info&Help Page in this article. The primary maintainers of these pages are the Q&A Team during the tests of the acceptance of the service.


Business Epic Pages

A Business Epic Page contains a description of an area of business.

The target audience for the business Epic pages are:

  • potential customers, which seek information on our products
  • developers which need basic understanding on the area of business they are developing software for

An Business Epic Page is typically structured with these content-sections:

  • Business Area - a general description of the business area and its specific requirements.
  • Challenges - descriptions of problems in this area and how these problems are solved by our Software Features (each with links to Sales Feature Pages)

All this should be described from a customer`s perspective, so that the customer understands what issues will be resolved by ZUGSEIL products.

The Product Pages are maintained by the Product Management Team.

Examples for Business Epics are Internal Ordering, Sourcing & Procurement, Warehousing, Fulfillment

Sales Feature Pages

Each feature enabled by a product has its own Sales Feature Page. A Software Feature is a set of functionality, which is defined by one or multiple business processes it covers.

The target audience for the Software Feature Pages are:

  • potential customers, which seek further information on our products
  • developers which need an a business perspective on the business on the service they are developing for

As a result the page focuses on the business case and value it provides (savings, automation level, ...) but not on the business processes on a detailed level, which are described in the Business Process Pages.

Each of these Feature Pages typically contains these content-sections:

  • Feature description - a general description of the business case the feature is enabling together with high level business process chains affected by the software feature
  • Business value - a business value description for the customer ("What value does it deliver for me?")
  • Business Processes - A text on business processes which are affected by feature (please provide links to the dedicated business process pages).

Each Software Feature Page also serves as Category Page for the User Journeys enabled by this Software Sales Feature.

The Product Pages are maintained by the Product Management Team.

Examples for a Feature is Regular Internal Ordering.

Business Process Pages

A Business Process Page provides a detailed description of a business process from its start to its end. They are closely linked to User Journey Pages, but describe the business process in an abstract business process engineering manner.

The Business Process Page contains these sections:

  • Reference workflow - a reference workflow of this business process (without providing screenshots). This description should be linked to User Journey Pages to enable the user how the coverage of this business process will look alike when he is using our software.
  • Step by step - a description of each step of the entire process. This description should be linked to Service Pages and Service Help Pages, where the service is are explained. In the case that a step is a subprocess, please create another Business Process Page for this subprocess, which is liked from the initial page.
  • Variations - possible variations of the process and reference to all software features which require this business process to operate.

The information should be not from the technical view but rather from the business analysts view, so that a person reading this page understands which value can be generated from our software to his processes.

The Product Pages are the main place for knowhow on our software. When development is planned the initial description is created by product or project management. When the initial creation process is covered, typically development management and support management contribute more to these articles. The target audience for the business process pages are:

  • potential customers, which more detailed information on our products and their solution space
  • project managers in training, which need to refresh or build their knowledge on how everything is connected in a business process
  • developers which need a full detailed view on the entire business process and its known variations for the development process.

Examples for Business Process Pages are:

  • Assisted Ordering for a team member
  • Laundry Bring-In at a Laundry-Shop

User Journey Pages

Each task the user wants to complete should have User Journey Page. The name of a User Journey Page typically starts with "How can I ... ". Each user journey page also is a category page, to which all Service Help Pages are linked which the user needs to visit, operate or use during the described user journey.

A User Journey Page contains these information:

  • Exact description of the task to be demostrated by this user journey
  • Step-by-step explanation of what to do (click through-explanation or even video)

Depending on the task of the user, the referencing user journeys can eventually span over multiple services and multiple business processes.

Examples for User Journey Pages are:

  • How can I get a quick overview of my orders?
  • How can I add a product to an entitlement?

Service Pages

For each b-op service developed by ZUGSEIL a Service Page is created by the manager responsible for specification for the development of the service. The target audience for the content of the service page are developers which should receive all information to implement this specific service. The service page is in the "Dev"-namespace which is only accessible to wiki-users having the permission to view the contents of this namespace.

As a lot of content is created from the b-op Service Descriptor by development automatically, it is essential for the creating manager to perform these steps:

  • add into the wiki-source page a reference to the service-uid by adding this content in the page in this form: <nowiki bop="ServicePage" serviceID="{service-UID}" />
  • make this page member of the category Servicepages by adding this line to the wiki-source page: [[Category:Service Pages]]

After this is done, the responsbile manager structures the content in these sections (each on Heading-Level):

  • Purpose - What the user can achieve with it?
  • Business Background - references to the business process pages which are relevant to this service
  • Layout - A description on "How does it look like?" (e.g. Mockups, Drawings, ... )
  • Functionality - A description "What should happen?" (foreground and background)
  • Acceptance Criteria - A description on what the QA-Team should look on. ("The tests planned for acceptance")

It is considered good practice to link as many other articles as possible to support developers and testers to produce as much quality output as possible.

Upon and during the development-phase the b-op wiki-page generators will then automatically:

  • append a "version-history" section containing a table of all versions and their states (planned, development started, in testing, publicly available)
  • creates the initial version of a Service Help Page, which is then populated by the Q&A team during the testing phase and by the support team after the golive.
  • create these subpages for each version
    • development history page, where developers can document important questions. The reponsible manager can then further clarify in the service page.
    • The configuration subpage, which contains all configuration options as defined in the b-op service descriptor
    • The dependency subpage, which contains the information of the b-op service descriptor in a human readable way
    • The compatibility subpage, which contains the information of the b-op service descriptor in a human readable way
    • The q&a test subpage, containing relevant information of the q&a process of this service