Blog

How does it work?

There are many widely used best practises or techniques for Business Process Modelling namely - BPMN (flow objects, connecting objects, artifacts & swin lanes), UML diagrams, Flowcharts, Yourdon' DFD, Functional Flow Block diagram etc. However, all of these techniques requires a pre-requisite understanding of their respective notations and symbols. Therefore, its quite often that models created using these technique looks good from an official sign-off or deliverables perspective but they hardly solve the purpose against which they were adopted in first place.

In addition to this, potential of misunderstanding or miscommunication, organizational standards, and contractual or regulatory obligations are also the factors to be considered in selection & adoption of right technique. As a Management Consultant, I help enterprises to choose and adopt to the right technique considering the given context of an enterprise.

Who is involved?

There are 3 key stakeholders who are involved in taking the ownership roles in process modelling. Depending upon the size of an enterprise, these roles can be played by one or more individuals.

Business process modelling will help enterprise to achieve 5 great things namely -

    • Helps improve business processes & promote innovation
      Helps train employee & promote knowledge sharing
      Helps in preserving enterprise business knowledge (intellectual property)
      Helps in mitigate risks and operational consistency
      Model vital part of patents and trade secrets

    • CXO Suite

    Define the enterprise level vision and mission statments. Provide timely sign-off on the demos. Actively participate in the sessions of understanding the 'As Is' and 'To Be' processes.

    Process Owner

    Define goals, tactics, KPI's, metrics and measures of processes. Monitor and report process performance. Come up with process improvement plans. Enforce process standards.

    Model Custodian

    Ensure that all the models are up-to-date & easily accessible within enterprise. Ensure models are available for inspection at any time. Maintain the repository of all the process model. Archive, store and destory obselete model.

    Management Consultant

    Organize material and design process model. Edit, standardize, or make changes to the models submitted by team members. Assist in preparing necessary diagram or matrices to ensure models are designed in simple language.

    Define Enterprise Strategy

    A critical aspect of enterprise business modelling is to define the overall business strategy because it guides the business modelling efforts. I work closely with your CXO Suite to develop the enterprise business strategy -

    • 1. The strategy must come from and be accepted by the business; it isn't an IT-only strategy
      2. Collaborate to define the goals, targets, and vision for your enterprise. Options for doing this include facilitated modelling sessions such as joint application development (JAD) meetings, less formal agile modelling sessions, or separate one-on-one interviews
      3. Set goals and targets are typically short-term, such as to grow the number of corporate banking customers (the goal) by 2% this quarter (the target), and are therefore likely to change on a regular basis
      4. Set vision, such as to become the largest retail and corporate bank in GCC region as measured by managed assets, is typically longer term and therefore less likely to change over time
    It's important to have an overall vision: if you don't know where you're going, you’ll never get there.

    • Model Business Process

    As a management consultant, I ensure that the business process model are inline with your enterprise's mission and vision statements. Pre-requisite to business process model, we need to describe -

    • 1. External environment - We need to understand the environment that it exists within and must identify your customers, in particular their needs (some of which are perceived and some of which may be motivated by your sales and marketing efforts). We must also identify the suppliers/vendors/partners of services and materials to your organization; perhaps you work with courier companies as part of your order fulfillment process. An important part of your environment is your competition: your rivals will be doing their best to lure your customers away from you by offering better value.
      2. Business Process - The business processes of an online retailer would include marketing, sales, order fulfillment, inventory management, and government reporting. An important part of enterprise business process modelling is the identification of the offerings (services and products) your organization provides to your customers, what you want to provide, and what you would like to stop providing. The next step is to identify, at least at a high level, how you go about (or should go about) doing so. Although the best practises suggests that use case models should be used for business process modelling, the fact is that many options are available to you as mentioned earlier, such as data flow diagrams (DFDs) and UML activity diagrams, and you should choose the ones that are best suited for your environment. Some models are good for logical process modelling, where you focus on what you need to accomplish but not how you'll do it; others are well-suited for physical modelling, where you focus on how the processes are accomplished. Some models can be used for either. This is where my expertise would be required to choose and adopt to a model in a given context of an enterprise.
      3. Critical Business Rule - As we explore the business processes within your organization, we will also identify critical business rules that we should capture. Our goal should be to focus on capturing the fundamental idea, such as the rule that a bank will charge a monthly fee for checking accounts, but do not go into the details (for example, specify what to charge for each type of account but not how to do it). Enterprise business rules should stand the test of time; they should describe business policies that will very likely still be in effect years from now.

    • Identify Process Implementation Options

    I help in identifying areas for process automation which is a key component of enterprise business modelling because it helps to put your IT efforts into context of the overall organization; IT must be viewed as an 'enabler of your business', not an end unto itself. Putting automation in the context of the business ensures that technology is not being implemented for it's own sake. Some processes will be fully automated, and some will be fully manual, but the vast majority will be somewhere in between.

    My philosophy is that the term 'process automation' can bias people towards IT solutions when manual ones are not only viable but also better options; therefore I personally prefer the term 'process implementation'. Similarly, new ideas for projects will be identified during the discussions, and information will then be provided to the portfolio management planning efforts in the form of a very informal project proposal (which could be something as simple as a few sentences on a whiteboard).

    Identifying potential ways to implement a business process is an art. If it wasn't, every retail store chain in the world would have seen the opportunity presented by the Internet and would have built their own version of Amazon.com. Furthermore, determining implementation strategies can be very difficult: the goal is to identify what to automate, what to perform manually (you'll still want to find ways to improve your manual processes), and what style of business process interactions you need between the various sub-processes.

    Model the Domain

    I work in liaison with your CXO Suite to create an important part of enterprise business modelling that is, a creation of a high-level domain/conceptual model that depicts the main business entities and their relationships that are of interest to your organization. This model, which does not need to be very detailed, is valuable input into the enterprise data modelling efforts of your information administration group as well as the requirements and business modelling efforts of project teams. In both cases the enterprise domain model provides a basis from which to begin more detailed modelling efforts: the project teams won't have to reinvent your domain model each time.

    In parallel we will also create an enterprise business glossary, which defines a common vocabulary within your organization. This enterprise business glossary is a valuable resource that should be shared with all of your project teams. It doesn't make sense for individual project teams to define common business terms such as "customer" over and over again because this can lead to wrong assumptions and incorrect data. Instead, teams should reference the commonly accepted enterprise business glossary and then focus on the terminology that is unique to their effort.

    Some organizations will attempt a domain engineering approach where high-level domain concepts are implemented in a reusable manner, perhaps as domain components or collections of web services. This approach requires significant sophistication within your organization, including a strong approach to enterprise business modelling as well as to enterprise architecture. Domain engineering represents the pinnacle of strategic reuse.

    Model the Organization

    Your organizational structure is what enables you to implement your business processes, and the two must be aligned if your organization is to succeed. Most people think of organization modelling as the creation of an organization chart, which depicts the reporting structure of your senior executives and line of communication. That's important information, but it's just a start. A true organization model describes your organizational units (teams, groups, divisions, and so on), the primary positions, the senior people, the roles and responsibilities that the people and organizational units fulfill, and the relationships (potentially including both reporting and flow of control) between them all. A robust model under such category of 'people and roles' may often help enterprises to save upto half a million dollars on SaaS or ERP implementation licenses.

    Support Project Teams

    It isn't sufficient to simply create enterprise business models and give them to your project teams because they probably will simply ignore the models. I've worked on development projects in several organizations where I discovered that many times an enterprise business model is available but that the teams never think to take advantage of them, if they even know they exist. Successful enterprise business modelers communicate their work to development teams and are willing to support the teams in taking advantage of the enterprise business models. The strategies of the agile community, particularly around improved communication and collaboration, are absolutely critical to your success at enterprise business modelling.

    It is quite common for organizations to mentor or train business analysts in process modelling skills and all developers in general analysis and modelling skills. It is also common for enterprise business modelers to take an active part on development teams, often in the role of business analyst. They will also develop and maintain appropriate modelling guidelines and standards (guidance) for enterprise business modelling. This guidance is often something as simple as the selection of standard modelling notation, such as BPMN or UML 2, as well as modelling guidelines. Your enterprise stakeholders should be part of the review process for your modelling guidance because they are an important part of the audience for your enterprise business models. In addition, you need to ensure that your guidance describes how to develop models that stakeholders will understand so that they can be actively involved in modelling.

    Model Categories

    An enterprise may choose one or more of the following model formats i.e. Matrices and Diagrams. However, I determine the specific categories and specific models within categories to be used.
    Represent organizations, groups of people,roles, and their relationships within an enterprise and to a solution. Techniques used to represent people and their roles include Organizational Modelling, Roles and Permissions Matrix and Stakeholder List, Map, or Personas.

    People and Roles

    Model Category
    Represent the ‘why’ of a change.

    Techniques used to represent the rationale include -
    Decision Modelling, Scope Modelling, Business Model Canvas, Root Cause Analysis, and Business Rules Analysis

    Rationale

    Model Category
    Represent a sequence of actions, events, or a course that may be taken.

    Techniques used to represent activity flows include Process Modelling, Use Cases and Scenarios, and User Stories

    Activity Flow

    Model Category
    Focus on features or functions of an enterprise or a solution respectively.

    Techniques used to represent capabilities include Business Capability Analysis, Functional Decomposition, and Prototyping..

    Capability

    Model Category
    Represent the characteristics and the exchange of information within an enterprise or a solution. Techniques used to represent data and information include Data Dictionary, DFD, Data Modelling, Glossary, State Modelling, and Interface Analysis.

    Data and Information

    Model Category

    If this sounds like your business case then,

    The best thing to do is call to action. There is no hard sell in this matter. Either I can help you or I can’t and it is pretty easy to tell both ways. If I am not the right person, I can usually suggest someone who might be.
    Book Now