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

Why choose ProVision®


Before we examine the context level in detail, here is a quick summary of why organizations select ProVision®. You can read more about the application in Chapter 6, Understanding the Toolset.

The world is changing faster. Anecdotal evidence indicates that a key aspect of your environment will change every quarter. Within the business it might be a new product line, a new service offering, a change in a process or the departure of a key manager. Outside of the business it might be the entry of a new competitor, the release of disruptive technology or a change in legislation. Whatever it might be, it will impact your work and the ability to do your job. The environment in which you operate is not stable.

The larger or more diverse your organization is, the greater these changes will impact you. To know what to do, and how to respond, you need to know more. Some observers argue that the rate of change is increasing exponentially. Therefore the situation is not going to get any better.

How do we gather this information? We talk, we browse, we research, we request, we listen. From numerous sources, a picture forms. Our co-workers do the same. We compare notes, we gossip, we text, we e-mail, we meet, we argue, and we fight. A rough consensus emerges—very rough. If we are honest, we will see that the picture is not complete, accurate or current. It is a mental model. It resides inside our heads. Our memory plays tricks. We forget and we distort. So does everyone else.

Important information is written down in reports, memos, websites, minutes, proposals, manuals, e-mails, and numerous forms. Not everyone knows how to write. Not everyone knows how to read. Workplaces employ people from various cultures where English is not always their first language. Even if it were, English is a pastiche, with layer upon layer of meaning laid down over centuries, like bark rings.

Creating pictures and diagrams is a good way to supplement the written word. Pictures offer an alternative way to grasp a hierarchy, process or workflow. Pictures are a universal language.

However, as the rate of change increases exponentially, we need a way to manage and maintain pictures easily. The same object might need to appear on multiple diagrams. How will we remember where they all are? How will we update them all?

This is the problem that ProVision® solves.

  • It is a visual relational database.

  • An object can be created once and used in multiple places.

  • Any changes made to one instance of the object instantly update all others.

  • Where several people are creating models, they can share them without overwriting each others' work.

  • ProVision® can import and export information to other sources. It can reference information stored in documents, websites, and the intranet.

  • It is a tool that will help you visualize and understand your business. Using it, you can collaborate with others to make better decisions now.

One could argue that these points apply equally to other modeling suites. The key differences that separate ProVision® from the rest of the pack are:

  • Ease of use

  • Scalability

  • Breadth of use

ProVision® is a product aimed at the top of the market, designed to manage thousands of objects, used by many different modelers. It has been used in numerous industries across the world. This means that local support is likely to be available. You will probably be able to find people with relevant experience and expertise to help you on your journey. Because it is relatively easy to use, organizations can get started fairly easily.

Personal context

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.

Time

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

  • You are thinking of using ProVision® (future user)

  • You already are using it and want to make better use of it (present user)

  • You used it and are no longer doing so (past user)

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.

Responsibility

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:

  • Responsibility for implementation

  • Accountability for implementation

  • Authority to implement

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:

  • Am I responsible, or have I been delegated to, implement ProVision®?

  • Am I accountable to implement ProVision® successfully?

  • Do I have sufficient authority to implement ProVision®?

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.

Scope

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.

Project scope

In this scenario, you are only responsible for a specific project and select ProVision® because you can see that it would make sense, from the whole of the organization's point of view. However you don't have the mandate to implement a central repository so you are trying to influence outside of your area of authority. This bottom up approach may or may not be successful. There are numerous examples of users pushing an organization in a direction that they didn't think of or plan for. Many organizations did not have a conscious strategy to implement Microsoft SharePoint. Users found it easy to do and they didn't have to wait for the IT department to build them a website. Suddenly the IT department found that there were numerous SharePoint sites that had been built under the radar.

The probability is that this approach will not work when implementing ProVision®. The key quality of bottom up is that it is frictionless. The change has to be so easy and smooth that it spreads like a virus. ProVision® requires training and a change of mindset.

So take the time to engage the people who are responsible for the enterprise. Get their agreement that your project will be the first phase of implementing an enterprise-wide strategy.

Enterprise scope

You are responsible for implementing a central repository and have selected, or are considering, ProVision® to do the job.

You have the opposite challenge from the person responsible running a project. How will you get users to put information into the central repository? How will you get them to change their behavior? How will you get them to see that it is worth having a central repository?

Fortunately, the solution is the same. The best way to build a central repository is one project at a time. Every project has to take time upfront to think, plan, and decide. The first project that is used to populate the central repository may take slightly longer than normal. However, as each project follows, the process gets faster and faster. More and more information that the project team will need access to, will be found in the central repository left there by the previous project team. It may need some updating but it is far easier to update information than to start from scratch.

Business context

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.

Recommendation

  • Before developing a strategy, first document your personal and business context for implementing ProVision®.

  • Get agreement on the context with all the key stakeholders. It is our view that the context in which success is most likely is one in which ProVision® is recognized as a tool for modeling the whole enterprise. This means that there has to be a commitment by senior business managers to create a central repository. Individual projects can then be used to populate the central repository, so that it gets built one project at a time.

Context is the big picture. The context document should only be one or two pages long and written in plain English. Here is an example of what it might look like:

Our organization operates in a complex world in which the rate of change is increasing. It is no longer possible for any one person to have a complete understanding of our business. Different parts of the business have developed their own specialized languages. Sometimes the same word means different things to different people. The word 'service' does not mean the same thing when used by a programmer as when used by a customer. While these special languages are essential, it makes it harder to have a shared understanding of who we are, where we are going and how we will get there, or simply communicate with each other and with our customers.

When people leave the business they take knowledge with them. As a result of all of these issues, decisions can be made without understanding the implications for other parts of the business. At the same time, it is simply not possible to document every piece of knowledge, so a balance must be struck. Therefore the business context for creating a central repository of knowledge about our business is that we want to make better decisions now.

We accept that better is more realistic than perfect. We will populate the central repository with just the information that is needed to make key business decisions. We will ensure that the information is current so that the decisions we need to make now are informed by the central repository.

In crafting this document, the language that you use will have a big impact. For example, we try not to use the word architecture. When you use the word architecture it conjures up images of buildings. This reflects the origins of enterprise architecture which examined how complex buildings and airplanes are maintained over many years. A jumbo jet might be in service for fifty years. During that time many parts will need to be replaced. The technology will change. The replacement part must fit precisely. The high level context of air travel is safety. How do you keep track of a million parts over fifty years?

Organizations are not buildings. They are people in conversation. Employees are not resources but people with lives outside of the business. As soon as you use the term architecture you are creating a mechanistic view of a business. Recent research by Gartner shows that emotional engagement is four times more important than rational engagement. By measuring how valued an employee feels by their line manager, you can predict accurately how long they will stay with the company. Lack of emotional engagement costs money. Most employees would prefer to be praised than get a pay rise.

In the first decade of the 21st century we saw the convergence of maps and data. Who can imagine not using Google Maps now? Over the next decade, we will see the emergence of tools that add an emotional layer to datasets. In ten years time, we will not just model how a process runs, we will visualize how stakeholders feel. We will redesign processes not to make them more logical and efficient, but to make them more enjoyable.