Book Image

Open Text Metastorm ProVision 6.2 Strategy Implementation

By : Bill Aronson
Book Image

Open Text Metastorm ProVision 6.2 Strategy Implementation

By: Bill Aronson

Overview of this book

Open Text ProVision® (formerly known as Metastorm ProVision®) is an Enterprise Architecture (EA) solution allowing for effective planning and decision making throughout the enterprise. It enables an organization to have a central repository of information about the business, reducing organizational risks and better optimizing business resources. Implemented well, it enables better and more actionable decisions exactly when you need them.This book combines theory and practice to provide a step- by- step guide to building a successful customer- centric model of your business. The approach is simple and down to earth, and along the way, with various real-world examples, you will learn how to make a business case, use a framework, and adopt a methodology with Open Text ProVision®. This book draws on the experience of ProVision® experts around the world. By combining theory with practice from the field you can avoid common mistakes and develop a successful customer centric strategy for implementing ProVision®. Each chapter builds on the previous one to give you the confidence to implement a central repository, dealing with both the technical and human issues that you might face.
Table of Contents (16 chapters)
Open Text Metastorm ProVision® 6.2 Strategy Implementation
Credits
Foreword
About the Author
About the Reviewers
www.PacktPub.com
Preface
References
Index

Project management methodology


Good project management methodology suggests that, before the project starts, you define the outputs, the outcomes, and the measures by which you will know if you have completed the work successfully.

Once the project is complete you conduct a post-implementation review to confirm that the work was done properly.

Despite this, many projects do not define the measures and never get round to doing a post-implementation review.

Many people are also confused about the difference between an output and an outcome. They use the two words interchangeably. Perhaps it is because the words are so similar. The purpose of a project is not to deliver outputs but outcomes. (If the people doing the work don't understand the outcomes, then they will not be able to do the best job possible.) Outputs are tangible 'things'. They are nouns. Outcomes are intangible. They are adjectives that usually end in 'er'. All outcomes, whatever the word used, come down to three key changes: better, faster, and cheaper.

For this first project the outputs that you will deliver are the strategy and a series of hierarchical lists of the key objects.

Note

The strategy is the documented business case, framework, methodology, and governance structure as discussed earlier.

These outputs are enablers. All that you have done is gathered information, most of which was known already. However, now it is inside ProVision®, and you can use of these standard objects to start building the models that you will use to make 'better decisions now'. Because you have done this preparatory work, the process of building the models will be better (you have lists of all the key objects at your disposal), faster (you can just use them, rather than have to create them from scratch) and cheaper (there will be a significant time saving in doing the second and subsequent projects).

Build sequence

The five key components of a business framework are defined as customers, products and service, critical processes, critical elements, and goals. We recommend that you build the lists in that order.

Customers

Customers come first, without customers you don't have a business. Therefore, you must start by defining who your customers are. There is another important reason. When creating models of your business, try to see what you do from the outside looking in. This is hard because our everyday experience is the opposite. We place our organization at the centre of the universe and our customers on the periphery. The more we can create a relationship with our customers, the greater the level of trust. Focus on the relationship and allow the customer to buy from you rather than sell to them. If you are not going to be building models yourself, but just want to understand the general principles, you can skip over the technical tips.

Note

Use the market object to represent classes of customer, and the organization object to represent specific organizations with which you do business. Place these objects on an Organization Model, with market objects at the top of the hierarchy and organization objects below. You don't need to represent every single individual customer and if you have many that might be impractical. Focus on general market categories, particularly as individual customers may come and go, thus creating a maintenance headache.

Products and services

Products and services come next, because these are the tangible things that cause our customers to come to us in the first place.

Note

Use the business domain object to represent products and the deliverable object to represent component parts. Please note that if you use the Enterprise Designer modeling language then business domain is automatically renamed product and the deliverable is called receivable. Represent products and services in a hierarchy on a Process Model.

Critical processes

The only way that we can deliver products and services in a consistent way is to put in place processes. Not all processes are critical to maintaining a good relationship with a customer. You may already have a methodology in place that you can use to rank processes. If not, in Chapter 4, Adopting a Methodology, we will look at a way to decide which processes are the most important.

Note

Represent processes on a process model. The process model permits you to use business domain, process and activity objects in a hierarchy. Business domain objects are used to represent the high level product or service that the process delivers. Because the activity object is more powerful, we recommend that you use it rather than the more obvious process object. Activity objects can appear in workflow models and be simulated. Since ProVision® does not permit activity objects to be linked to business domains directly, make a process object with the same name to act as a link. When you are publishing models, hide the process object as it might cause confusion.

Critical elements

Once we have identified the critical processes, we can then see what elements are the most critical to make these processes run.

In the Enterprise Designer framework we identify seven elements that are used to run processes. They are (in alphabetical order):

Actors

Actors are people performing work manually. Internally, you will start by creating a hierarchical list of business units, position descriptions, and roles. Externally, you will start by creating objects for suppliers, customers, regulators, and competitors.

Note

Use the organization model and organization objects to create an 'org chart' of the business. Use the person object to represent positions within business units. If there are more than one of any type of position, use one object to represent them all. Do not use the role object on an organization model. Later, you will use the role object in workflow models.

Business rules

As a process runs, the way that the work is done will be shaped and influenced by rules, legislation and practice. By documenting rules, you will help simplify and standardize business practice.

Note

Use the rule object on a business rule model to represent specific business rules. Use the standards object on a standards model to represent legislation, standards, and less specific advice and guidance. Typically, business rules are set internally and standards are part of the environment in which the business operates.

Best practice for rule specification is to include the following elements in each rule statement:

  • Rule Subject (what the rule is about)

  • Rule Keyword (for example, must, may not, is)

  • Rule Qualifier (for example, if, when)—optional

  • Literal—optional

Computer systems

Increasingly repetitive work is done automatically. Some processes are now completely automated (such as requesting a bank balance at the ATM). Others are partially automated (obtaining cash from the ATM). Some are primarily manual (getting financial advice from your bank). ProVision® is very good at modeling business processes and can even simulate them running.

Note

Use the systems object and the systems model to represent hierarchies of systems or computer applications. Remember that systems are software applications, not the hardware upon which they run.

Data

Processes consume data. At each step, data might be created, read, updated or deleted. Information is the lifeblood of a process.

Note

Start off by using the business class object on a business class model. Later, you may wish to explore package objects and models, and subtype models for more sophisticated data modeling.

Events

All processes are triggered by events. Within each process, the individual activities are also triggered by events. Typically, the completion of the previous activity is the trigger. This is how BPMN classifies events:

  • By type: message, timer, error, escalation, termination, and so on

  • By origin (in relation to the process participant): external (for example, message), internal (for example, signal)

  • By timing (in relation to the process): start, intermediate, and end events

  • By role: send (throw) a result, listen for (catch) triggers

  • By effect (on the process): interrupting, non-interrupting

  • By scope of influence: all the internal workings of a process or activity, or just the flow on which they are placed

  • By trigger configuration: multiple events—only one required, multiple events—all required

This is an example of a request event. Time events such as end of day or end of financial year start a process irrespective of what has happened. Threshold events trigger an action when a certain point is reached. For example, start manufacturing when we get 50 orders.

Note

Start off by using the event object on the event model.

Facilities

All processes take place in specific locations. Even if the process is fully automated, there is still a place, albeit a server rather than a specific office.

Note

Use the location model and represent places with the location object, and specific offices, factories and other buildings with the facilities object. If necessary, represent specific pieces of gear, such as servers, as children of facilities using the equipment object.

Gear (equipment)

Many processes rely on gear or equipment being available to support the actors. They use these tools (furniture, equipment, computers, mobile phones, and so on) to get the job done.

Note

Represent equipment or gear on the location model.

Goals

Goals come last, not because they are least important, but because they are the hardest to gain consensus on. When an organization changes its goals, people can lose their jobs or be assigned work which has less responsibility. Naturally, goals are political and, depending on who you speak to, you may get different answers, when trying to define them. Later, we will show you a way to define goals which does not depend on a personal point of view. In effect the goals of an organization can be reverse engineered.

Note

There is no need to create goal models early on. You may wish to delay these until the senior management begins to get an appreciation of what you are creating. When you are ready, start off by using the goal object on a goal model. Add measure objects for each goal. Don't overload goals with too many measures.