Where do we start to build a strategy? Let's start with a working definition. A strategy is a plan to achieve a goal. Every situation may require different strategies and different plans. However, it is possible to apply a consistent way to design a strategy. The benefit of doing so is that everyone involved learns a consistent language.
In this first chapter I will show you a five-layer strategy framework, developed by global business coaching company Shirlaws (www.shirlaws.com.au). It can be applied to any business issue that you want to understand in greater detail. The five levels are:
Typically, organizations do not pay sufficient attention to the second level and jump straight from Level 1 (context) to Level 3 (implementation). Level 2 (strategy) requires the organization to slow down in order to speed up. As a result, they do not get the full benefits and are unable to leverage.
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.
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:
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.
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.
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 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.
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.
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.
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.
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.
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.
The Capability Maturity Model describes the maturity of organizational processes. Five levels of maturity are defined starting at the initial or chaotic, repeatable, defined, managed, and optimized: http://en.wikipedia.org/wiki/Capability_Maturity_Model.
This is very curious. I don't know any individual who runs a company who publicly acknowledges that they are not mature enough to do their job. How is it that an organization that is run by mature individuals can argue that it is immature? If it really is immature, why is this said with a shrug? Surely the recognition of immaturity should be treated as a major crisis!
This issue around immaturity is now being addressed by business coaching. Coaching provides an organization with a common language and set of frameworks. It enables an organization to reflect on the causes of the immaturity and discover ways to transform them.
Once an organization has agreed a context, it is very tempting to jump straight into implementation. By taking the time to craft a strategy, the implementation phase will go more smoothly. It does mean that you have to slow down to speed up, and this can feel frustrating. We know what the problem is. Why not just jump in and fix things along the way?
Context answers the why question. Strategy answers the what question: what are we going to do differently? Implementation answers the how question.
In the remainder of this book, we will describe the key aspects of the strategy in more detail. The strategy document can be divided into sections in accordance with the key aspects of the strategy, namely:
Making a business case
Using a Framework
Adopting a Methodology
Implementing effective Governance
Understanding the Toolset
Here is an example of what a strategy overview might look like:
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.
Once the strategy is agreed, the Program Management Office, or equivalent, can determine the sequence of projects that will be used to populate the central repository. A typical project should take no more than three months from start to finish. The initial project will be to gather core information that will be required by all subsequent projects. In the Enterprise Designer framework this core information is defined as:
Who are the Customers?
What are the Products and Services we provide to them?
What are the Critical Processes required to produce these Products and Services?
What are the Critical Elements that drive the Critical Processes?
What are the Key Goals of the Organization?
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:
Who is responsible for initially gathering the information?
How do you name objects?
Who ensures that the object is maintained?
Where is the object stored?
What is the publishing process?
How much detail does the object require?
How do you get the information from another system into ProVision®?
How do you prevent duplicate objects and what do you do when you find them?
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® 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.
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:
Overall responsibility for defining, explaining and ensuring that the naming convention is followed
Overall responsibility for ensuring that models and objects are kept current
Overall responsibility for defining and managing the publication of models
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.
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].
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.
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).
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.
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.
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.
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.
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.
In the Enterprise Designer framework we identify seven elements that are used to run processes. They are (in alphabetical order):
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
Congratulations! If you have made it this far you have designed a strategy and got it approved. You now have a business case, an agreed framework, methodology, and governance structure. You have created repositories and developed a process by which you can publish your models. You have populated the repository with key components that will be used again and again. In alphabetical order, these critical components are hierarchical lists of the following business objects:
Products and services
They may not look like much. After all, you did not need to purchase ProVision® just to make lists. You could have done that in Microsoft Word or Excel. These lists are the building blocks from which you will start to assemble models. So now what do you do, to create value?
We recommend that the first model you build to show to stakeholders is a Client Service model. (If you sell products to customers, then you may wish to call it a Customer Product model.) Throughout this book we will use the terms interchangeably. This model is often overlooked. It visualizes which clients get which services. In an outside-in view of the world, the customer comes first. Therefore it is essential that you have a way to express the relationship between who your clients are and what they get.
Use the navigator model to build the Client Service model. Populate the model with the customer and product objects you created previously. Use communication links to express the relationship. You can remove any objects from the model which do not add clarity without breaking the relationships. Senior managers must own this work. Once the Client Service model is complete, do not proceed to the next step until they have approved it.
You now have a bare bones repository of information about your business. The next step will be determined by the priorities of the business. There will be specific projects that will be candidates as the 'first cab off the rank'.
In determining which projects to select, we recommend that you choose the ones which are mission critical. It is tempting to choose a project that is low profile and low impact. It is also tempting to choose a project because the project manager is happy to have your help. This way you can iron out the bugs, build skill, expertise, and confidence in a safe environment.
Please resist this temptation. Remember that something significant in your environment will change within three months. This might be that the champion goes off to do another job or even leaves the company. Their replacement may not like what you do at all!
Therefore, each modeling project must demonstrate value to the business every three months. Making lists of processes is important and essential. It does not demonstrate to anyone outside of the modeling team that your costs are worthwhile.
So, within the first quarter, make it your business to model the benefits that a key business project will have. If it is a critical project then the senior managers will know that it is critical. If it is technical in nature, they might have little understanding of what is actually being done. By creating models that visually demonstrate what the project is about, you can help that project team and the senior management team. In some cases your models will actually enable the senior managers to understand the project for the first time.
Each project you model from now on needs to be critical, in the eyes of senior management, and related to the previous projects. In this way, much of the information that would normally need to be gathered is already populated. This does two things. First, it saves time, speeding up the work of the project team. Second, it provides a mechanism to validate and update the previous data. Information goes stale, so that even if it was correct three months ago, it might not be now.
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.
You have learned a five-layer framework. Typically, organizations do not pay sufficient attention to the second level and jump straight from Level 1 (context) to Level 3 (implementation). Level 2 (strategy) requires the organization to slow down in order to speed up.
You have learned that the context of any set of actions is more significant than the content. What is the context for deploying ProVision® in your organization? Context precedes strategy, and strategy precedes implementation.
You have also learned that the business may have a different context to your personal one. The business may not have an understanding that ProVision® is an enterprise tool. ProVision® is a good enterprise solution. Before developing a strategy, first document your personal and business context for implementing ProVision® and get agreement on the business context.
You now understand the key parts of a strategy document. The strategy document consists of six sections that are described in more detail in the following chapters:
Making a business case
Using a Framework
Adopting a Methodology
Implementing effective Governance
Understanding the Toolset
The initial project will be to gather core information that will be required irrespective of what the second and subsequent project is.
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.
You now have a business case, an agreed framework, methodology, and governance structure. You have created repositories and developed a process by which you can publish your models. You have populated the repository with key components that will be used again and again.
You now have a bare bones repository of information about your business.
Each project you model from now on needs to be critical, in the eyes of senior management, and related to the previous projects. In this way, much of the information that would normally need to be gathered is already populated.