Open Text Metastorm ProVision 6.2 Strategy Implementation: Create and implement a successful business strategy for improved performance throughout the whole enterprise

One might argue that the context of any set of actions is more significant than the content. Our day to day experience is content-based and so we tend to be unaware of the context of our actions. If the context is not articulated, then different people will have different contexts. When this happens, we perceive others as having hidden agendas. Our own context seems obvious to us, and we assume that it must be obvious to others.

Context simply means why? Why are you contemplating ProVision® or implementing it? It is a piece of software, albeit a very flexible one. It is easy to make the mistake that the tool itself will provide you with a strategy for its implementation. In fact, context precedes strategy and strategy precedes implementation. That is why this chapter does not provide any details of ProVision's features and functionality. There are three key contexts that affect how you approach ProVision®—time, responsibility, and scope.

A lifecycle is characterized by three states—past, present, and future. Where are you in the lifecycle? What is your knowledge and experience?

Each of these user groups has a different context. The future users have a vision and perhaps little or no experience. Their expectations may not match what is realistic. Their vision is an idealized view of what the tool offers. The present users have experience and thus their expectations are different. They are better able to distinguish between the promise and the performance. The past users will have formed an opinion or judgment, either positive or negative. If they believed that the tool was a panacea, then they may have a jaundiced view.

The second context concerns your position within the company. In order for you to implement ProVision® effectively you need three things to be a part of your job description:

In my view, the true meaning of responsibility includes accountability and authority. Let's clarify what we mean by these in more detail. This doesn't just apply to implementing ProVision® of course. It applies to all work. If you understand the distinction then you will dramatically improve your ability to do your job. If you educate others within your business then you will dramatically improve the effectiveness of your organization.

Responsibility means that it is part of your job description to make this piece of work happen. Responsibility doesn't mean that you do the work, although you might. Responsibility means that you are the one who is ultimately meant to make it happen. Can you delegate responsibility? Yes.

What happens when you delegate responsibility? Does that mean that if something goes wrong then you can blame the person to whom you delegated? No. Let's see why not.

If you have responsibility for a piece of work it means that you are also accountable. Simply put, accountability means that there is a clear and objective test as to whether the piece of work has been done. By designing this test before the work is undertaken you can review whether it was done to the appropriate standard. What happens when you delegate responsibility for a piece of work? The delegate is now accountable. However, the accountability has not been passed from one person to the other. Rather, a new accountability has come into existence. You have created it out of nothing. You are 100% accountable, they are also 100% accountable.

The alternative approach doesn't work. How can you say that you are 20% accountable and that the delegate is 80%? These divisions are meaningless. You can no more be 20% accountable than you can be 20% pregnant. While responsibility can be delegated, accountability cannot. The blame game can only happen when accountability is split.

Finally, authority means that you are able to do what you think is the best thing to do in order to get the work done. You have the funds, the people, the equipment and the decision making ability. You can make it happen. Your level of authority has to match both your level of responsibility and accountability. If, at one extreme, you have authority that is greater than your accountability then you are a dictator. If, at the other extreme, you have insufficient authority then you are a helpless victim.

Well run companies ensure that everyone's roles clearly define responsibility, accountability and authority. Great managers make it their business to ensure that these are well understood. Great salesmen discover quickly if they are talking to a person who has responsibility, accountability and authority. If not, they know they are wasting their time, trying to sell to someone who will never be in a position to buy.

So ask yourself these three questions:

If the answer is no to any of these three questions, then the only way that you will succeed is by pure luck. Many organizations delegate responsibility for a piece of work but do not give the delegate the authority that they need. If you are the manager and are not prepared to give the delegate the authority that they need, then it is better that you do the job yourself. Of course that then begs the questions why you don't trust them? You are meant to be a manager, right?

When you take responsibility at a context level, your focus is on how you can empower others around you to become responsible. You understand that responsibility simply means being 'able to respond'. If you talk to someone who is taking context-based responsibility, key words to listen out for are enjoyment, easy, excitement and play.

When you take responsibility at a content level, your focus is on how you can do everything yourself. You equate responsibility with having to do everything, so it becomes a burden. If you talk to someone who is taking content based responsibility, key words to listen out for are serious, duty, obligation, and work.

Often, it is hard to tell the context that you are operating under as it is often unconscious. A simple way to discover your context is to look around you. The way that people work with you correlates exactly to your context. If you are the only one who is being held responsible, and you work in an organization that has a blame culture, that is what you have created. If you transform your context, then everyone around you will start to transform theirs as well.

There are two types of scope that are relevant here. You might be running a specific project and think that ProVision® will be useful. Alternatively, you are responsible for managing all of the corporate knowledge of itself. Let's examine each scope.

We have described three contexts that apply to you personally. In addition to you as an individual, the business will have its own context. This will probably be different to yours. You may have been selected to be responsible because of prior experience and expertise. Your understanding may even be far ahead of the rest of the organization.

The business may not have an understanding that ProVision® is an enterprise tool. Its success is dependent on an enterprise-wide implementation strategy. The strategy comes first. The tool is not a panacea. Does the business understand that its most valuable asset, perhaps, is its knowledge of itself?

Let me provide a metaphor. You want to build a picket fence and have not done so before. You are buying tools and are thinking a lot about whether to get a nail gun or just use a hammer you already own. You think so much about this issue that you come to believe that the success of the project depends on buying the nail gun. The nail gun is a good tool and will make the job easier. However if you don't know what type of wood to use, how deep to dig the holes for your posts, or how far apart they should be spaced, having a nail gun is not going to result in the best outcome.

When selecting a modeling 'nail gun', large organizations often send out detailed questionnaires to vendors. Can it do this? Can it do that? Is it compliant with this standard? Can it export in XML? Does it comply with TOGAF? Can I customize the application?

They assemble all the answers and then pick the tool that they can afford which gets the most ticks.

They then look at Gartner and Forrester, and gather reports on the vendors. ProVision® is consistently a leader in these reports. However the information is of limited value. The research organizations test products in the lab not in the real world. The people who test have only a limited amount of time to conduct their review.

This process is an essential prerequisite and yet more is required to lead to the best outcome. The success of enterprise modeling is not just about features and functionality. ProVision® is a good enterprise solution. There are other products which have similar features and functionality. Success occurs when you understand your context and create the appropriate strategy.

ABC Co. has three wholesale divisions that sell electricity, gas and telecommunications. The telecommunications and gas businesses were acquired. Currently the organization has difficulties in responding to customers because each division is a silo. Customer information is not centrally available and we are not able to cross-sell effectively. In effect we are three separate companies.

This project will create a central repository of information about the organization in order to understand who we are today and how we can become one company. The Board has selected the Enterprise Designer framework and methodology to capture the key information. Population of the central repository will be done one project at a time. All major projects will contribute to, and extract information from, the central repository.

ProVision® is the tool that will be used to capture, maintain and present the information. This toolset has been selected as it is capable of capturing all the key information about the organization relatively quickly. As we gain greater expertise, we can add ProVision's server-based repository, Knowledge Exchange®, to enable greater communication and collaboration. We can also bring the models into Metastorm Open Text Business Process Execution. This will allow us to describe a process in ProVision® and then track individual process instances in real time.

The Program Management Office that reports directly to the Board will have overall responsibility, accountability and authority for this initiative. The Board has appointed global business coaching company Shirlaws to advise them on implementation strategy.

As you can see, these are all lists of components and they are normally arranged into hierarchies.

In the example above, we see that a type of ProVision® object called a market has been used to describe three major customer groupings: Electricity, Gas and Telecommunications. These major groupings can decompose down further into sub-customer groupings as required. As we create a model and add objects to it, ProVision® updates the object inventory. There is no need to add objects to the object inventory first. We can create them 'on the fly'.

ProVision® provides a toolkit of common objects, such as markets, organizations, processes, elements and goals, out of the box. If necessary, you can create custom objects to extend the standard set or you can rename objects to match your corporate language. For example, in the Enterprise Designer modeling language, we have re-named the Business Domain object and called it Product.

So, before you begin to create more complex models, you need to create lists of the objects that might be required in many different situations.

There are several issues around building lists:

As you can see, building and maintaining a list is not as easy it might seem at first. Besides the technical issues, there are issues around maintenance, governance and standards. Let's look at these issues more closely.

Many organizations start off with a team of two or three professional modelers. Their background is likely to be business analyst, system architect, business architect, or enterprise architect. They will either have a business process or technical background.

Part of their job is to work with subject matter experts who have the best appreciation of what each list should contain. The subject matter experts will not normally learn how to use ProVision®. One approach is for the modeler to have a conversation with the subject matter expert and extract the relevant information. The problem with this approach is that it transfers ownership from the subject matter expert to the modeler. When changes occur, the modeler may not find out.

The alternative approach is for the modeler to create an Excel spreadsheet template and help the subject matter expert populate the information. The benefit of this approach is that the subject matter expert can maintain the list, using Excel, a tool with which they are familiar. The modeler can then import the list to ProVision® on a regular basis, catching any changes.

Because ProVision® stores an object once, any changes will update instantly in all of the models in which the object appears.

ProVision® does not enforce a naming convention. The organization must define their own and put in place a mechanism by which all users adhere to.

ProVision® offers the option to number objects. These numbers are not part of the object name but appear as if they are. Thus the same object can have different numbers in different models. For example an activity in one model might have the prefix 1.03 in one model and 6.4.1 in another. This can create confusion.

Therefore, we recommend that objects either have no numerical prefix, or the numbers are hard-coded and are part of the object's name. In this way they will appear in a consistent order in any list.

The key point to remember is to treat the number as a unique identifier, not as a sequence number.

The benefit of putting a unique ID at the start of any name is that the text that appears afterwards can change, without it losing its unique character.

For example, imagine that you have an activity object called Undertake Assessment. When you look in the object inventory it will appear with other activities that start with the letter 'u'. If you decide to change its name to Perform Assessment then it will now appear alongside the activities that start with the letter 'p'. Another modeler, unaware of the name change, may not find it. However if you call the activity 36112 Undertake Assessment, you can change it to 36112 Perform Assessment without it changing its position.

The disadvantage of using a numerical prefix is that all objects now appear in numerical order in the object inventory.

We recommend that you have an upfront discussion about the naming convention, document your choice, and ensure that everyone follows the same convention. One compromise that is worth considering is to use number prefixes for all key objects. Individual modelers are not permitted to create new key objects. They can, however, create child objects which do not have a numerical prefix.

This discussion about naming conventions reveals the need for a role that is responsible for managing the central repository. We need to distinguish between the technical and business aspects of this role. If there is a large team then the role might be split. The technical aspects of the role include:

ProVision® stores information in repositories. Within each repository the modeler can create multiple notebooks, models and objects are created inside notebooks. A metaphor you might use is that a repository is a bookshelf, a notebook is a book on a shelf, a model is a chapter in the book and an object is a word in the chapter.

In a small team, where there are just one or two modelers, the working repository will be stored on a local drive with appropriate backup strategies in place. A static published version might be stored on the corporate intranet.

However, once you start to have larger teams, the recommended approach is to upgrade ProVision® by adding the server-side component Knowledge Exchange®. This enables several different modelers to work together through formal version control procedures. If one person is updating a model, the objects therein are 'checked out' to that person. This prevents other modelers from overwriting changes. Meanwhile, if they need to use the same objects, they can check them out as 'read-only'.

As objects are checked back in, Knowledge Exchange® automatically makes a web version of the current state of the repository. Interested parties can watch the models change over time using Internet Explorer. They can even be given rights to comment on the models and add details, directly from their browser.

Once Knowledge Exchange® is installed it is best to store these lists on the server. The latest version of the application allows the user to store objects remotely on the server and then reference them in the local repository.

We recommend using a three-step process. In the first step the modeler creates a notebook on their local hard disk and builds models. This notebook will contain models and objects that are not for publication. For example, they may sketch a model and discover it is not useful. Once a model is ready for review it is transferred to the QA repository. This is an easy process. If Knowledge Exchange® is not installed the modeler drags the model from one location to the other. If Knowledge Exchange® is installed they check the model into the QA repository and notify the person responsible.

The QA repository administrator reviews the model and determines if it is ready for publication. The stakeholders check the model and either accept it or request changes. Once the model is approved, the QA administrator transfers the model to the Production repository where it is visible to anyone who has been given rights to view it.

The process might look like this:

The bare minimum is the name of the object and its type. There is no requirement to add any further information. To keep objects looking clean and simple onscreen, all the detail is stored in hidden tabs, which can be accessed if required. We recommend that all objects that are published include a short description.

ProVision® supports a number of ways to transfer information and is compliant with standards such as XML. The simplest way to transfer information is to import it from an Excel spreadsheet that has been formatted to comply with the ProVision® data structure. There are a number of wizards which will aid the import process from other products, such as Visio. If these manual and semi-automated methods are not suitable, a developer can create a custom routine which would take information from another system and import/export it automatically. This routine would ensure that the information about the object remains consistent in both places.

It is not always essential to create an object in ProVision®. If the other source is a document or web page, it may be far easier to use the artifact feature. This is essentially a hyperlink. The user clicks the link and it opens up the relevant page. This approach eliminates the need to synchronize the two locations as the external source becomes the master and ProVision® becomes the slave.

Use artifacts to link to manuals, procedures, business rules and similar documents that may be stored on the corporate intranet.

How do you prevent duplicate objects and what do you do when you find them?

If you define a naming convention, and ensure that everyone understands and follows it, you will reduce the chance of duplicate objects. It will still happen. ProVision® treats object names as case sensitive. Thus an organization object called Finance is not the same object as finance or FINANCE. Therefore, your naming convention will need to decide on the correct format to try and reduce duplicates. Activity objects should follow a convention such as [Verb] + [optional adjective] + [Noun].

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.

Project #1 captures the complete list of products and services of the company and the critical processes which underpin the key products and services.

Some benefits: The complete list of products and services can then be mapped against the corporate website. This will identify gaps. Products and services that don't appear on the website can be added based on the old adage that if you don't tell you won't sell. Redundant products and services can be removed from the website.

Business interaction models provide a clearer image of what the business is about, improving induction training.

Project #2 develops workflow models for the critical processes.

Some benefits: You discover differences in the way that the same process is done in different divisions. There is no need for these variations, which have emerged over time due to silos in the business. Using appreciative inquiry, you identify the best known way to run the processes. This creates a cost reduction of 20% and the process time is cut in half. Because you used appreciative inquiry, the staff involved feel energized by the change.

Project #3 develops system interaction models of the systems that underpin the critical processes identified in Project #2.

Some benefits: The IT department now has a complete list of critical systems. They know who the process owners are in case of a system failure. They leverage this to form the basis of their business continuity plan.

Project #4 develops a business class model of the information that is created, read, updated, and deleted in the critical processes identified in Project #2.

Some benefits: Now the business can see where information is stored in different formats across different systems. By standardizing, the business can have a shared understanding of the customer. Before this project, the same customer might appear in two different systems, and it was nearly impossible to know that they were the same.

Project #5 develops an organization model of the business units and positions that participate in the critical processes. Combining this with the information that came from the workflow models in Project #3, it is now possible to create a grid which maps position descriptions to roles.

Some benefits: Instead of a position description being purely descriptive, it can now be expressed as a collection of roles. If a position needs to change, you can immediately see all the processes that will be impacted. In a business continuity event you can query the repository for all other positions which have the necessary skills.

Each project reveals information in a way that was never available before. Each project builds on the previous ones and makes the repository richer.