GLoW Business Documents
All GLoW business process documents are in this chapter.
- GLoW Roadmap
- GLoW Diagrams and Charts
- GLoW Business Rules
- GLoW Procedures
- GLoW Document Maintenance Schedule
- GLoW Roles and Responsibilities
- GLoW System Design
- GLoW Best Practices
- GLoW Policy
- GLoW Contacts
- GLoW Workflow Checklist
GLoW Roadmap
Common knowledge is about your experience and what you know.
Critical knowledge is about your expertise and how you think.
This project is being carried out under the aegis of the
Truth Beauty and Goodness Commission.
Introduction
What is the Global Library of Wisdom (GLoW)?
GLoW is a digital knowledge base that has been specifically curated to contain data that is categorized as wisdom. Wisdom in this case pertains to what is commonly referred to as best practices, and their opposite, bad practices.
The Global Library of Wisdom:
- Has a goal.
- Has specific inputs.
- Has specific outputs.
- Uses resources.
- Has a number of activities that are performed in some order.
- Creates value for the user.
There are three main types of GLoW processes:
- Management processes: these are the processes that govern the operation of GLoW and are usually administrative in nature, such as regular backups and process documentation maintenance.
- Editorial processes: these are the processes that constitute the core business of GLoW, and deal primarily with the production and control of content and its input into the GLoW knowledge base.
- Supporting processes: these are the processes that support the core operational processes. These supporting processes usually have to do with the creation and maintenance of specialized tools used by the other processes, such as the New Content Submittal Form.
What is the purpose of the Global Library of Wisdom?
The purpose of GLoW is to make accessible to the public a curated collection of well structured and highly focused wisdom relating to planetary management best practices, and bad practices, oriented towards the eventual achievement of planetary Light and Life status.
Documentation for the Global Library of Wisdom.
The result of business process modeling is a collection of documents of various types. Some are long, some are short, some are graphical, and most are text. It is important to keep these documents well structured and concise, using plain language. The style used is less important. While they are generally technical in nature, the documents must nonetheless be user friendly for the people who will use them. The documents follow the hierarchy indicated below.
The GLoW business process model consists of the following core documents which are located at: [LINK TO DOCUMENT REPOSITORY]
This Roadmap document that you are now reading is part of these core documents, and it explains the main concepts and reasons for modeling the GLoW system, its associated resources, and how to maintain them.
- GLoW Diagrams
A xxxx file containing various diagrams that are used to visually map out the GLoW process. These diagrams use the Business Process Modeling Notation 2.0 (BPMN). This is a high level document which only provides an outline of the process in a graphical format. It explains what needs to be done. - GLoW Business Rules
This document contains the various business rules used to understand the process. This is a mid-level document which exposes the logic of the process. It explains why things are done. - GLoW Procedures
This document contains the various procedures used to execute the process. This is a low level document which exposes the details of the process. It explains how things are done.
Additional Support Documentation.
The following documents are located in: [LINK TO SUPPORTING DOCUMENTS]
- New Editor Orientation (onboarding manual for new editorial staff)
- System Administrator Orientation (onboarding manual for new System Admins)
- GLoW Specifications Manual (details of GLoW system for IT staff)
- BPMN Spec 2.0.pdf (reference manual for BPMN specification)
Maintenance of GLoW documentation.
Maintaining the documentation that makes up the GLoW business process model is an ongoing activity, and is the responsibility of the entire GLoW Operational Team. Complete maintenance details are contained in a separate GLoW Document Maintenance Schedule.
Process diagrams are at a higher level than business rules, and should only be changed when the process changes. Changing the process diagrams can lead to many changes in the business rules. Changes to the process diagrams should be considered carefully by the entire GLoW Team since they reflect significant changes in the organization. Changes to the process diagrams should always be done in accordance with the BPMN 2.0 standard.
Business rules are at a lower level than the process diagrams. You can change a business rule without changing the process diagrams. Business rules are easier to change and maintain than the process diagrams, and can be done by the individual(s) who have the knowledge that needs to be recorded in the rules. Once a change is made to a business rule, the entire GLoW Team should be notified of the change. There are currently no widely accepted standards for writing business rules, however, they generally fall into the category of technical documents, and should always be user friendly for the people who will use them.
Procedures are at the lowest level. You can change a procedure without changing the process diagrams or the business rules. Procedures are easy to change and maintain, and can be done by the individual(s) who have the knowledge that needs to be recorded in the procedures. Once a change is made to a procedure, the entire GLoW Team should be notified of the change. Procedures should always be user friendly for the people who will use them. Procedures change often and they require frequent maintenance.
Whenever you revise one or more of these core documents you should also append the document’s version history table, usually on the second page, or the version number located at the bottom of the sheet in the case of a diagram.
GLoW Diagrams and Charts
GLoW - Assessment Process - BPMN Diagram
GLoW - Submittal Process - BPMN Diagram
GLoW - Editorial Process - BPMN Diagram
GLoW - Publishing Process - BPMN Diagram
GLoW Business Rules
"At this point, in this process, given this information, what action should be taken?"
Introduction
This document is one of several that are used to describe the workflow of the Global Library of Wisdom (GLoW).
Purpose
This document describes the various business rules that regulate the development, management and use of the GLoW. This document is designed as a technical reference manual with each rule a collapsible block. There is no fixed reading order so feel free to jump to the section(s) of interest.
Document Conventions
The business rules in this document are structured as follows.
Note: There is a ready made business rule template in TBG Workspace > Documents > Templates to assist you in creating new business rules.
BR # Business Rule Name
This gives a unique reference number to each business rule and declares the rule’s name. Either or both of these are used as references in other documents, and are often referred to in the GLoW BPMN diagrams. For clarity, the business rules should be named (to the extent possible) according the tasks or sub-processes that make up the GLoW workflow.
Definition
A brief description of the business rule. The language used should be unambiguous and easy to understand. The words used must have unique meanings within the GLoW business domain. Important terminology should be referenced in the Glossary section of this document.
Conditions
Explains the logic, and decision making that is part of the business rule. Should use words such as if, and, or. Is usually expressed in the form of one or more questions.
Action
Outlines the steps, methods, and procedures required to execute the business rule. Numbered lists can be used to describe a controlled series of steps. Bulleted lists can be used to describe ad hoc procedures.
Deliverables
Some deliverables are optional, such as drafts, and some are mandatory, such as approvals, the Forms Action Request, or other official process forms.
Participants
Identifies the persons, services, and business units involved in the business rule.
When not required
Explains the conditions that allow this rule to be skipped.
Note
Additional information that is of importance to the execution of the business rule. Notes should be kept brief and to the point.
BR 1
|
BR 1 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 2
|
BR 2 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 3
|
BR 3 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 4
|
BR 4 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 5
|
BR 5 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 6
|
BR 6 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 7
|
BR 7 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 8
|
BR 8 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 9
|
BR 9 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
BR 10
|
BR 10 Business Rule Name |
|
|
Definition |
|
|
Conditions |
|
|
Action |
|
|
Deliverables |
|
|
Participants |
|
|
When not required |
|
|
Note |
|
Glossary
|
Business Rules |
Business Rules describe the operations, definitions and constraints that apply to an organization in achieving its goals. |
|
Procedures |
Procedures are detailed explanations that staff members follow in order to execute the corresponding business rule(s). Documented procedures are used to describe the knowledge underpinning an organization, allowing it to perform its functions. It covers a wide spectrum of knowledge, skills, know-how and expertise which define an organization. Procedures represents the most important operational asset and covers the following organizational knowledge: documented procedures, methods & policies, compliance with external rules, regulations and legislation, staff know-how and expertise relating to users, products, services, resources, processes, operations and risks. |
GLoW Procedures
“The Only Source of Knowledge is Experience” - Albert Einstein
Introduction
This document is one of several documents that are used to describe the Global Library of Wisdom (GLoW) workflow. Refer to the References section in Appendix for additional documentation.
Purpose
This procedure document contains the collective experience of the GLoW team. It describes the specific conduct, methods, routines, processes, and actions used to execute the GLoW workflow. This document is designed as a technical reference manual. There is no fixed reading order so feel free to jump to the sections of interest.
Document Conventions
The procedures in this document are structured as follows.
Note: There is a ready made procedure template in TBG Workspace > Documents > Templates to assist you in creating new business rules.
PN # and Procedure Title
This gives a unique reference number to each procedure and declares the procedure’s name. Either or both of these are used as references in other documents. For clarity, procedures should be named (to the extent possible) according the tasks or sub-processes that make up the GLoW workflow. The procedure title should be carefully selected so that it is simple and clearly conveys the procedure’s content.
Definition
A brief description of the procedure. The language used should be unambiguous and easy to understand. The words used must have unique meanings within GLoW's domain. Important terminology should be referenced in the Glossary section of this document. The definition describes the overall objectives, functions, or tasks that the procedure is designed to accomplish and the circumstances under which the procedure should be used.
Responsibility
Lists units, offices, and individual job titles for those who have responsibility for aspects of daily control and coordination of the procedure, authority to approve exceptions to the procedure (if applicable), and procedural implementation (including responsibility for any required electronic or written documentation). Sets forth the scope of responsibilities under the procedure, the procedural areas subject to discretionary modification (if any), and the responsibility for implementation.
Procedure Details
Using an approach which is customized to the subject (i.e., can be a statement in outline format of each step required, a checklist of what needs to be done, an explanation of how to complete the necessary steps – including screenshots if applicable – or an appropriate combination of techniques), provide the reader with the necessary procedural and “how-to” and "best practices" information to get the job done. Use bulleted lists for collections of tasks that don’t follow a specific order, and use numbered lists for tasks that must be followed in order. Included in this section should be definitions of unique terms or terms subject to different interpretation and copies of all forms needed to complete the procedure.
References
Indicate the sub-processes and business rules that this procedure applies to.
Resources
A table which points users to training material, additional documentation, templates, forms and other sources of help for carrying out the procedure.
What are the characteristics of a good procedure document?
The goal for any procedure document is for the design to be simple, consistent, and easy to use.
Good procedures
Procedures are tied to the business rules and the overall workflow process. Procedures are developed with the customer/user in mind. Well developed and thought out procedures provide benefits to the procedure user. There is a sense of ownership among procedure users. For this reason, it helps to involve users in the development of procedures. The procedures must be understandable. Procedures should be written so that what needs to be done can be easily followed by all users. When feasible, procedures should offer the user options. Procedures which are unnecessarily restrictive may limit their usefulness.
Writing style for procedure documents
- Use the active voice (wrong: the editor will send an approval email to… correct: the editor sends an approval email to…)
- Avoid speaking to the past or the future, speak only in the present.
- Write as if the subject does the action (wrong: a GLoW entry is designed… correct: the Editor designs a GLoW entry)
- Be concise, and use a minimum of verbiage.
- Factual — double-check accuracy!
- Don’t include information that may be quickly outdated (e.g., names, phone #).
- If you use an acronym, spell it out the first time you use it (e.g., Global Library of Wisdom (GLoW) ).
- Include step-by-step instructions. Use numbered lists for instructions that must be followed in order. Use bulleted lists when the order of the list is not important.
- Not too technical — simple enough to be understood by new staff.
- Always include resources (e.g., “include full link to the source document”. Don’t forget to indicate where the reader can get resources. Add such information in the Resources section.)
- Always write from the point of view of a person who has never done the procedure.
Design and layout of procedure documents
- Generous use of white space.
- Presentation is structured so that the user can quickly focus on the aspect of procedure relevant to their decision/task at hand.
- Layout each procedure in a table (provided in the Templates section).
- Use a flexible, modular outline to make the document easy to modify and keep up-to-date.
- Use labels to introduce key points (headings and labels in margins need to be consistent ... i.e., same location on each page, type size, etc.).
Responsibilities of procedure owners
Procedure “owners” are accountable for the timely review, updating, and dissemination of procedures in their functional area. Assignment of responsibility for procedures is accomplished partly through a series of delegations of authority. Alternatively, in the absence of a formal delegation, authority will rest with the unit which has been assigned operational responsibility for an area.
When developing new, or revising existing procedures, procedure owners have an obligation to identify those who will be directly affected by new or revised procedures and to consider a representative sample of their views early in the procedure development discussions. They must also ensure that their procedures adhere to the principles of, and achieve the objectives of GLoW. In addition to documenting the approved procedure, the owner should develop support and training options, if appropriate, for the customers/users who are attempting to adhere to the procedure. This includes, at a minimum, the designation of “experts” to which staff can turn for guidance or to resolve problems.
PN 1
PN 1 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 2
PN 2 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 3
PN 3 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 4
PN 4 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 5
PN 5 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 6
PN 6 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 7
PN 7 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 8
PN 8 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 9
PN 9 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
PN 10
PN 10 Procedure Title |
|
|
Description |
|
|
Responsibility |
|
|
Procedure details |
|
|
References |
|
|
Resources |
|
Glossary
|
Business Rules |
Business Rules describe the operations, definitions and constraints that apply to an organization in achieving its goals. |
|
Procedures |
Procedures are detailed explanations that staff members follow in order to execute the corresponding business rule(s). Documented procedures are used to describe the knowledge underpinning an organization, allowing it to perform its functions. It covers a wide spectrum of knowledge, skills, know-how and expertise which define an organization. Procedures represents the most important operational asset and covers the following organizational knowledge: documented procedures, methods & policies, compliance with external rules, regulations and legislation, staff know-how and expertise relating to users, products, services, resources, processes, operations and risks. |
GLoW Document Maintenance Schedule
x
GLoW Roles and Responsibilities
x
GLoW System Design
BookStack wiki software
The Global Library of Wisdom - GLoW - is a knowledge base built with a wiki system called BookStack.
BookStack website: https://www.bookstackapp.com
Screenshots: https://www.bookstackapp.com/#screenshots
Documentation: https://www.bookstackapp.com/docs/
The BookStack system uses a bookshelf metaphor, where shelves are used to contain collections of books, with each book consisting of chapters (optional) and pages. Each book page essentially consists of a simple yet elegant html web page which holds the primary content of the knowledge base.
The shelves, books and chapters are used primarily as content structuring tools, but also serve as user friendly and intuitive navigational aids for logically and easily drilling down to specific portions of content by offering the user both a breadcrumb trail and an expandable hierarchical table of contents.
Like any good digital knowledge base the BookStack system comes equipped with a versatile and powerful built-in Search tool (Meilisearch) for doing keyword searches.
The BookStack Release v22.09 aims for at least WCAG 2.1 Level A standards for accessibility.
The GLoW framework
The GLoW implementation consists of four fundamental layer of information. 3 layers of metadata and 1 layer of content.
- First metadata layer: Shelf (only 1 shelf used for identifying GLoW).
- Second metadata layer: Books (at least 10 books representing top level categories).
- Third metadata layer: Chapters (many chapters per book).
- First content layer: Pages (many pages per book/chapter).
The GLoW books
This screenshot shows the 10 GLoW books used for labelling the top level categories. Each book has an optional text field for entering a brief description of the book. Any number of chapters and pages can be added to a book. When appropriate, pages can be added directly to a book without being part of a chapter.
The GLoW chapters
Each GLoW book may contain any number of chapters that may be useful for sub-categorizing the wisdom entries. Chapters can be used as an additional structural layer for containing content pages. In the BookStack system chapters are optional. When appropriate, pages can be added directly to a book without being part of a chapter. Similar to books, each chapter has an optional text field for entering a brief description of the chapter.
The GLoW pages
- Each GLoW page is a simple html web page conforming to the default BookStack style and design.
- Each GLoW page is a repository of wisdom pertaining to a specific subject.
- Each GLoW page may contain one or more wisdom entries.
- Each wisdom entry on a page begins with a header used for classifying the entry, and indicating one or more jurisdictions that the entry falls under. See header example below.
- The header is also used for recording the source of the wisdom entry when available.
- The header is a pre-configured BookStack page template which can be inserted anywhere in a wisdom page.
|
||||||||
| SOURCE: | ||||||||
How the wisdom coding system works.WISDOM CLASSIFICATION SYSTEM Type of wisdom (purple box) E = Evolutionary wisdom Target audience (green box) P = Personal Type of content (yellow box) C = Curated content (paraphrased, re-written, enhanced, translated, etc.) Reliability factor of content (blue box) 1 = High APPLICABLE JURISDICTION(S) [ ] soil [ ] Land [ ] Sea [ ] AIR
|
GLoW Best Practices
x
GLoW Policy
x
GLoW Contacts
x
GLoW Workflow Checklist
A check list of all the steps needed to get the job done.