A BusinessOptix library is a central repository for your Business Architecture holding business process and data models, master data and configuration for your organization.
This document provides recommended guidelines for the governance of a BusinessOptix library.
Individual organizations are expected and encouraged to tailor these guidelines to suit their own specific requirements and preferred working practices.
The first recommendation is to run an introductory workshop, to
- Facilitate agreement on tailored guidelines
- Document and use tailored guidelines as material for subsequent training in BusinessOptix
The next section of the document discusses this workshop.
The remaining sections discuss each of the key elements required to promote adoption and minimize rework:
- Library roles and responsibilities
- Library structure, including folder structure and user access control
- Modelling, including process models and master data
- Configuration and customization opportunities
I. Introductory Workshop
The purpose of the introductory workshop is to review, revise as necessary, and agree the Governance Recommendations provided in this document.
In the process, workshop participants will gain familiarity with the BusinessOptix library.
II. Scope
Most of the recommendations in this document may be revised. The only exceptions are those on which the reliable operation of the library depends:
- Overall Library Structure
- DO use a single “Master Data” folder and it's sub folders
III. Workshop Preparation Considerations
| Question | Answer |
|---|---|
| Who do I need to invite to the workshop? |
The attendees should include
|
| Do I need to bring any project materials to the workshop? | Yes, if you can bring examples of existing project scope documentation and any existing process documentation examples |
| What format will the workshop take? | The workshop will constitute a round table discussion of how best to create and publish process documentation |
| How long will the workshop take? | The full workshop runs across ½ day – this time allows for debate and decisions to be made |
| What are the anticipated outputs from the workshop? | Agreed set of guidelines for the governance of process modeling and the usage of the BusinessOptix Library |
| Will only the workshop attendees benefit or also the wider audience? | The outputs will be such that all future projects will follow the published guidelines ensuring standardization of approach and resulting documentation |
1. Library Roles and Responsibilities
| Role | Responsibilities |
|---|---|
| Library Owner |
Responsible to the organization for the governance of the library:
|
| Library Administrator |
Responsible to the Library Owner for:
|
| Section Owner |
Responsible to stakeholders for ensuring that models in their own particular section of the library:
|
| Author |
Responsible to the relevant Section Owner for creating and editing models within their section. Authors should be assigned to groups, corresponding to the sections they work in. An Author may be assigned to multiple groups. In particular, there should be a Master Data Authors group, responsible to the Library Owner for maintaining the library’s Master Data lists (except for very large libraries, these will usually also be members of other groups). |
| Process Owner |
Responsible to the organization for the real process (or other entity) whose model is maintained in the library. In the case of Master Data, the Process Owner should be the Library Owner. The Process Owner’s role in modeling is often restricted to final approval. |
| Process Specialist |
Responsible to the Library Owner for providing guidance and assistance to Authors, to ensure the consistent application of modeling guidelines across all areas. Should be experienced in process development and applicability for business process improvement. |
| Reviewer |
Responsible to stakeholders for reviewing new and modified models, and providing feedback to the Section Owner and Author. Reviewers should include
|
| Approver |
Responsible to the organization for signing off new and modified models, prior to formal publication. Approvers should include at least the Process Owner. |
2. Library Management
2.1 Overall Library Structure
At the topmost level, the standard BusinessOptix library has a fixed structure, comprising a standard set of configuration and content folders.
2.2 Configuration Folders
These folders hold the configuration information which determines what the library can contain, and how it can present that content.
With the exception of the Reports folder, which any user can browse and open reports from, only the Library Administrator can access these folders directly.
| Folder | Contents |
|---|---|
| Shared/Reports | All the live reports available for the library |
| Attachments | Any uploaded files will be stored here, mainly for images and non-BusinessOptix documents |
| System |
Stencils (which determine what types of model are available and what content is allowed in each type). Styles (which define the different types of HTML, PDF and Office document output provided by the library). |
| Workflow | Active workflow definitions and in-flight instances of those workflows. |
| Recycle Bin |
Files deleted from the library. The Library Administrator can copy files back out of here. |
The TAILORING section of this document describes the ways in which these folders can be used to tailor the library to the organization’s specific needs.
2.3 Content Folders
These folders hold models, along with outputs (such as HTML pages and PDF documents) generated from those models.
| Folder | Contents |
|---|---|
| My Work |
‘Scratch’ working area for each individual Author, used for experimentation, partial models, and other content that is either not intended or not ready for collaborative use. Authors are free to create any internal structure they wish within their My Work areas. |
| Shared |
Collaborative area for model development. Unlike the other areas, keeps earlier version of every model. Individual versions may be checked out to guard against concurrent updates by multiple Authors. The definition and management of folders within the Shared area is discussed under SHARED FOLDER STRUCTURE below. |
| Stakeholders |
Published models and outputs
The internal structure of the Stakeholders area always mirrors that of the Shared area. |
2.4 Shared Folder Structure
The structure of the Shared (and, by extension, Stakeholders) folder is managed by the Library Administrator.
The design for this should be one of the outcomes of the introductory workshop.
Experience with many customers over several years has led to some DOs and DON’Ts…
DO use a single "master data" folder
One invariant is the presence of a Master data folder directly under Shared: all standard stencils expect all Master Data list models to be held in this folder. In order to prevent uncontrolled changes to Master Data files, this folder should be protected by making it read-only for all but Master Data Authors.
DO import existing collateral to a staging area
Existing Visio diagrams can be imported directly into BusinessOptix – but the quality of these diagrams can vary widely, not only from one organization or department to another but from one individual diagram to another.
Always import to a staging area (such as Draft Maps) in the Shared folder, and perform an initial review of the imported content. Once the imported models can be matched with the planned Shared folder structure – which may require moving processes from one model to another, or splitting up some and joining together other processes – start moving models into the target areas.
DO mirror your organizational structure
The remaining Shared folders should reflect your organizational structure. This approach facilitates:
- A hierarchical name space, that is easy and intuitive for users to browse and find a model of interest
- Easy to manage access control, by protecting selected ‘Section’ folders, each with its own Section Owner, so that they may only be read and/or written by the relevant user groups (see USER ADMINISTRATION).
DO use familiar business names for folders
Always use the same names for your folders as your stakeholders use for the organizational entities they represent – however long or short those names may be, or however cryptic they may be. The purpose of the hierarchy is to make it easy for your users to find their way around, so use the signposts they are already accustomed to.
DO use simple 'verb noun' names for process models
For process models, use a simple “verb noun” name that describes the purpose of the process – for example, “Handle Complaint”. This makes library navigation easier for users.
DO keep the structure shallow
Avoid nesting too many levels, which makes it difficult for users to navigate the library. In extreme cases, overly nested folders can run into limitations on the length of file paths imposed by Microsoft Windows.
If your organization has many layers, either consider revising it as part of your Business Architecture transformation, or only introduce a sub-folder at those points where access control is required, and otherwise store models for multiple units within the same folder.
DO use Diagrams as a graphical site map
Use Diagrams to provide a graphical site map, giving users an overview of your organization, with drill-downs to top-level process and other models.
This lets users navigate by whatever means you provide, instead of being constrained by your Shared folder structure.
DON'T base the folder hierarchy on drill-downs
Traditionally, process breakdown structures have reflected the relationships between processes, with sub-processes at any one level placed in a sub-folder of the one containing the higher level process which calls them.
This may sound like it would make the navigation between folders consistent with the user journeys promoted via the published HTML. In practice, however, it seldom works unless your processes are highly siloed – often the reason for undertaking a process modelling exercise in the first place.
In addition, the approach breaks down wherever a common sub-process is called from multiple higher-level processes, forcing the creation of artificial ‘Common’ folders at one or more points in the hierarchy.
Provided you also use diagrams to provide a graphical site map, following your organizational structure actually gives your users more navigation options: they can drill down (and follow breadcrumbs back up) across organizational boundaries, or they can browse the organization via folders and dive directly into their selected process.
DON'T prefix folder or model names with numbers
Traditional process breakdown structures often use a hierarchical numbering scheme. When your “process repository” is a set of flat files, this may make sense – if you take a file out of the repository, the fact that its filename begins with a series of numbers (like headings in a legal document) means you still know exactly where in the hierarchy it belongs.
But BusinessOptix process models have searchable metadata, including numeric codes (whether generated automatically or by hand), so there is no need to include these in the filename as well. Doing so makes it harder for humans to infer the meaning from a model name, which in turn makes it harder to navigate the hierarchy.
Users can still find models by these internal codes, using the library’s standard search capabilities – so if they know the code for a model, they can find it directly without needing to browse their way down the folder hierarchy.
2.5 User Administration
The Library Administrator is responsible for
- Applying protection to the Master Data and any other relevant Shared folders
- For each protected folder, indicating which groups have read, and which write, access
- Allocating users, including new joiners, to groups as required, on an ongoing basis
3. Modelling
3.1 General Recommendations
The recommendations in this section apply to all types of model.
DO allocate each model to a single Author
The BusinessOptix Library offers a check-in/out mechanism, at the version level, to prevent possible confusion when more than one Author attempts to edit the same model at the same time.
It is better to avoid the need to use this feature, by adopting the working practice of having a single Author be responsible for each model during the course of any project.
DO identify model Owner, Author and Stakeholders
All BusinessOptix models include a common set of metadata, used to make it easier for users to search for models and, in some cases, as information required by workflows. Some of this metadata is maintained automatically by the library, some must be entered by the Author.
In particular, you should always provide the following, for every model, as they are used by workflows to provide notifications to participants:
- Owner: historically, the biggest single cause of failure in process improvement initiatives is the lack of an identified Process Owner
- Author and Owner Emails (the Author is maintained automatically)
- Review and Approval Stakeholder names and email addresses
DO verify models
Use the Verify command (on the Actions ribbon) to check models against rules.
For all models, they include checks for the presence of required metadata properties.
For Process models, they also include comprehensive checks against the BPMN standard. Several of these produce Warning rather than Error messages: you can safely ignore these, at least during the initial build phases of the library.
3.2 Process Models
The Process model follows the BPMN 2.0 standard. The main components of a process are:
| Component Type | Usage |
|---|---|
| Lane |
Shows accountability (where the buck stops). Use the accountable role name as the name of the lane |
| Pool | A black box pool represents an entity external to the business process |
| Activity | Shows work to be performed, whether by a human or a system (or a sub-process). |
| Event |
Shows an interaction with something outside the process (such as a message or a timer):
|
| Gateway |
Shows where alternate or parallel paths start or end. NOTE that a gateway is NOT a decision: it shows how the process proceeds as a result of a decision. |
| Data Store | A store represents a storage facility |
| Information | Shows information or other deliverables being produced or consumed by the process. |
| Link | Shows the sequence of steps in the process. |
| Note | Show additional information that is important for users to be aware of, and that they might miss if hidden away in the text |
| Group | Visually group closely related activities |
| Image | Additional pictorial information (such as screenshots) |
DO keep names short
To avoid cluttering the diagram, keep component names short, and put explanatory text in the Description property. For activities, use ‘verb noun’ – e.g. Place Order.
DO review models
The Section Owner should review models to ensure
- Processes pass Verify checks, and properties have been completed consistently
- Consistent usage of model components (including activity, event, gateway)
- Consistent use of Master Data (especially Responsible, Accountable, Consulted, Informed)
DO regularly visit which properties should be populated
The importance of different sets of properties will vary as the library matures. Initially, only the properties on the first page of the Properties Inspector will matter. At some later point, you will probably want to add metrics and other information.
The Library and Section Owners should decide which properties should be filled at any stage. With the default stencils, this is a manual review exercise – however:
- Custom Reports can be used to list all models missing information of a given type
- Custom Stencil extensions can be used to make any property ‘required’ so that the Verify command will detect and report missing values
See the TAILORING section for a discussion of these capabilities.
DO use gateways to describe routing
When there are multiple steps that can happen next in a process, use a gateway to make this explicit. If you do not, different people may make different assumptions about how the process works:
- Do the following activities all start at the same time, and proceed in parallel?
- Does the process choose just one of the following activities?
By using a gateway, you avoid this ambiguity. For a default gateway, only ONE of the following steps will be taken:
Whereas by explicitly making the gateway parallel, you unambiguously show that BOTH following steps start and proceed in parallel:
DO label conditional links
When a link is conditional – as it usually is from a gateway – always give it a label so that users understand which step will be performed next under different circumstances.
DON'T use a gateway without an activity to show a decision
A gateway does NOT represent a decision. Decisions are made by a user or a system, and imply at least some degree of effort – and effort should always be modeled as an activity.
Instead, use an activity (where the decision is made) followed by a gateway (where the result of the decision determines the route(s) to be taken).
DON'T put too many components in a single diagram
If you try to cram too much onto a single process diagram, you
- Make it hard for users to follow the logic
- Force browser users to use either the scrollbars or the zoom control
- Make the diagrams difficult to read in PDF output, where they are squeezed in order to fit on a single page.
As a rough rule of thumb, more than around 20 components on a page starts to be difficult for users to assimilate. If your process is more complex than this, you should break it into manageable pieces and treat each as a separate sub-process.
Note that this is one of the GOOD reasons to keep multiple diagrams in a single model.
3.3 Master Data Models
Master Data models provide a simple way of maintaining a set of hierarchically organized lists, whose contents can be referenced from any other model.
The standard library Master Data models are:
| Master Data Model | Contents |
|---|---|
| Deliverables |
Information, products or materials produced and/or consumed by processes. These can be associated with
|
| Glossary | Frequently used acronyms/ industry terms that can be explained/ detailed centrally and the associated with all elements / components |
| Locations |
Geographical areas or locations where activities are performed, associated with:
|
| Roles |
The roles representing people (or systems) involved in processes, associated with:
|
| Skills | Centrally defined set of Skills with associated descriptions which can then be associated with People within the organization chart |
| Systems |
Systems, applications, services or other technology used to perform activities, associated with:
|
DO provide and maintain master data
With the standard Process stencil, users can choose Master Data resources for the properties shown above, or enter their own “local” resources if no suitable Master Data item exists. Local resources are stored within the model in which they are used, rather than centrally.
Using Master Data rather than local resources allows you to search and report on all uses of any particular resource, across the whole library, so you can quickly understand the impact of changes to that resource.
You cannot do this with local resources. And if you begin by using local resources and then decide to move to Master Data, there is no simple way to translate local resources to Master Data, since users may have used even slightly different names for the same resource, and the Library cannot reliably determine that two local resources actually mean the same thing.
For these reasons, it is important to build Master Data lists early, and to maintain them. Once created, it is easier for users to select Master Data than to create local resources, and the effort to add the occasional new resource to the Master Data list is easily manageable.
You do NOT need to worry about getting the hierarchical structure of Master Data lists right first time: you can move resources from one position in the hierarchy to another at any time: all models that use the modified resource will automatically pick it up from its new location.
DO review use of local resources
The standard ‘Model Issues’ dashboard offers many views of model resources and can be a useful in creating and maintaining models.
3.4 Output Styles
Output styles determine the look and feel of the documentation generated by the library. The standard BusinessOptix library includes a set of output styles that should meet most immediate requirements.
About half of our customers require content (as opposed to purely style) modifications: this can be provided by BusinessOptix or its partners or, if customers have in-house expertise with XML Stylesheets (XSLT), by customers themselves.
DO install your own logo
All standard output styles pick up their logo from the library, so the Library Administrator should upload your logo to the library manage area. Logo files may be uploaded by clicking Manage Library then the Customize Home Page configuration from the Manage menu. (Admistrators only) Logos can be uploaded for the header used within the library or the PDF outputs.
DO review all output styles
Check all the standard output styles to see which, if any, cover your needs. A common requirement is for pure style changes (fonts, colors, etc.). If you have an in-house web design resource, these can be modified quite easily via the (for HTML) the standard CSS file or, for PDF, the standard Corporate PDF XSLT file.
3.5 Stencils and stencil extensions
Stencils determine the type of content that can be stored in the library: each available model type is described by a stencil. The following stencils are provided as standard with every library:
| Stencil | Use |
|---|---|
| Diagram | Free-form ‘home’ and other high-level navigation pages (e.g. Target Operating Models). |
| Document | A model for generating text documents, broken into sections |
| Forms | HTML forms allow you enter and submit information |
| Process | End-to-end business processes and sub-processes, using the industry standard BPMN notation |
| Lean | Lean (6Sigma) Value Streams at a conceptual level |
| Organization | Org charts. |
| Report | A report allows users to query the contents of a library and generate tables and charts |
| Master Data |
Master data lists, used to eliminate re-keying and ensure consistency across the library. The following are provided as standard:
|
| Workflow | Automation of recurrent library activities, such as Review and Approval cycles |
Each stencil defines:
The types of component that appear on the Components ribbon
How they appear – and may be connected – in diagrams
Where they appear in the Table of Contents
What trays that appear in its Properties Inspector
DO provide tailored model templates
When a user creates a New Model, they are presented with the contents of a predefined template – itself a BusinessOptix model, of the appropriate type, which lives in the System/Stencils folder alongside its stencil.
This can be modified (by the Library Administrator) to define Introduction and Conclusion (text) sections and sub-sections for every model of its type, to provide common context to each model.
DO consider stencil extensions
Stencil extensions are small files which live in a sub-folder associated with each stencil, used to:
- Define new or modified Property Inspector trays and properties
- Modify the appearance of diagrams
- Add new types of component to models and diagrams
- Add new types of Master Data
Most customers have some degree of customization made in this way: this can be provided by BusinessOptix or its partners or, if customers have in-house expertise with XML, by customers themselves.
DO tailor workflows
Workflow models provide a simple automation mechanism for common Library tasks, such as producing documentation and managing Review and Approval processes.
The standard library ships with a single Approval workflow. This can be found in the library's Workflow folder.
The standard Approval workflow is provided as a working example. Every organization will have its own different requirements for the Approval process. Anyone with any familiarity with Process models will find it easy to modify and create Workflow models.
3.6 Dashboard and Reporting
Dashboards and reports allow users to view information about models across the whole library, rather than on a model-by-model basis. They can be found in the Insights folder of the library:
The BusinessOptix library comes with a selection of standard reports and dashboards which are often extended. The standard Dashboard report shows a selection of standard reports as a dashboard, with drill-down links to the full versions of each
Dashboard tables can be sorted by column and most dashboard graphs will drill-down to hyperlinks to more detailed information or even models. Dashboard tables can also be exported to Excel.
Others display various charts, like these examples found in the Library status dashboard.
Comments
0 comments
Article is closed for comments.