Business Process Management

Archive for the ‘Business Process Management’ Category

The new process modelling - visualizing processes

Thursday, October 27th, 2011

You can’t improve collaborative human work unless you can see it. In other words, you need a means of visualizing what is going on before you can even start to standardize then manage work with an eye to making it more efficient and effective.

For complex, high-level work, this is pretty much impossible without using Human Interaction Management (HIM). Planning and workflow tools show you task sequences but not the team and communication structures that enable productivity, empower negotiation, and increase use of knowledge. Further, task sequences in themselves embody a danger, in that using such an inappropriate means to describe complex human work typically results in either a restrictive level of constraint or a dangerous freedom (and often both).

By contrast, HIM provides a simple, business-oriented way to understand what is going on in a complex, high-level work process, by grouping work into goal-directed Stages, in each of which specific Roles work together in a structured way to produce and share Deliverables.

HumanEdj, the software tool for HIM, provides a number of visualizations. There are core operational views for current Plans, showing your personal outstanding work items and the status of each Stage. There are multi-layered views to provide context, showing the structure of each Plan and Plan template in terms of Stages or as conventional GANTT charts (but with advanced features about which I’ll say more in future posts). There are tabular views of Plans and Plan templates that can be copied and pasted into a spreadsheet. Finally, there are resource allocation views, that show by Plan and by person the amount of effort allocated to different processes.

Many of these views identify forms of action that may be required by managers to keep work on track, either by adjusting the structure of work processes or by re-allocating the people assigned to them. In the next posts I’ll look at this in closer detail. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Case Management, Human Interaction Management, Management | No Comments »

The new process modelling - what about DCM?

Thursday, October 20th, 2011

Traditionally, the worlds of project management and process management have focused on different areas. Managers who use project planning techniques are strong on forecasting and monitoring the allocation of people to tasks and the resulting costs. Managers who prefer process-oriented techniques are strong on improving the way in which work is carried out, for example via techniques such as Lean Six Sigma. The project planning approach works well for one-off situations and the process improvement approach works well for work that repeats in much the same way. But what about work that doesn’t fit neatly into either category?

Much human collaborative work not only repeated (i.e., a candidate for improvement) but also highly adaptive - so flexibility on the ground is critical for success. To deal with both concerns, you need a combination of the forecasting/monitoring supplied by project management tools with the structured approach supplied by workflow tools.

This may appear to be close to the domain of Dynamic Case Management (DCM). However, cases do not have the same kind of formal structure as workflows, so it is hard to improve them. Their operation can be tightened up using business rules, but this is not the same thing as finding new and better ways to execute the work. The DCM approach is fine for the sort of low-level work in which it is safe to let the operator make their own judgements about how to do it (simple problem resolution, licensing, medical diagnosis, mortgage processing, invoice discrepancy handling, equipment maintenance, insurance claim processing, and so on). However, DCM is unsuitable for the sort of high-level, business-critical, and often very expensive work that typically crosses boundaries (complex problem resolution, research & development, marketing, complex sales, services delivery, merger & acquisition, organizational change, and so on). This latter kind of work needs careful management, for which managers need to see its structure in a helpful way, and tools that empower people from different organizations to collaborate naturally.

In particular, this means providing a combination of the resource and cost planning/monitoring features found in project management tools with the simple, clear depiction of underlying structure found in workflow tools - although with human collaborative work, you need a different kind of structure. Assigning tasks in sequence and describing their outputs is not enough.

In the next posts I’ll look at how HIM makes repeated, adaptive human work visible, thereby empowering people to improve it via the 5 principles. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Case Management, Human Interaction Management, Management | No Comments »

The new process modelling - a typical Activity

Wednesday, October 19th, 2011

In the last post I explained why HIM Activities provide a way to capture, maintain and re-use knowledge gained during execution of work items. Here I’ll give an example to illustrate.

Consider a project to set up a new government organization. In HIM terms, there will be a Stage with the goal of setting up premises with associated physical network and computing equipment. Let’s suppose that the number of staff is large enough that creation of this IT infrastructure will be outsourced via request for tender.

A key Activity in the Stage will be to gather requirements for the IT infrastructure, including details of the components required: illustrative usage scenarios, deployment types, benefit profiles, state changes, related service processes, service-level agreements, and so on. These requirements will be used as input to a Request For Quotation (RFQ), so the key output from the Activity is text, appropriately formatted for use in a RFQ document.

However, the Activity will also produce a number of other outputs. For example, gathering and analysis of the requirements will make use of a dedicated requirements management tool, to assist with completeness and consistency checking. Hence the repository created via use of this tool is also an output of the Activity - it may not be directly used to create the RFQ, but represents valuable knowledge that may well be used by the supplier that wins the bid, both to set up the infrastructure initially and also for on-going maintenance.

A further, even more indirect, output of the Activity is the way in which it was carried out - in particular, the work that was done to select a requirements management tool. This may involve, for example, a feature comparison using reports from analyst firms as well as a price comparison that required contacting vendors for quotes. The selection of the tool may turn out to be quite a time-consuming and complex task in itself, so its outputs are certainly worth re-using on future occasions that staff of the organization need to gather requirements. Even if their needs are different on other projects, it is bound to save them time if they can refer back to the outputs of this selection process.

In both cases, the value of the indirect outputs are enhanced immeasurably by their association with the requirements gathering Activity - without that, they are unlikely even to be found by the people that need them on a later date. Especially as the organization grows, knowledge such as this will become buried in a vast network of documents and data - unless HIM processes are used as a route map to traverse the network. HIM Plans provide a means to join up all work in an enterprise, from strategic decision-making at the very top, to low-level automated workflows at the grass roots.

In the next posts I’ll look at resource and cost planning/monitoring using HIM processes. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management, Knowledge Management | No Comments »

The new process modelling - what do Activities produce?

Tuesday, October 18th, 2011

In my last post, I asked what an Activity actually produces? Is there anything else than the expected outputs that come from doing a particular piece of work?

The answer, of course, is that knowledge also arises from doing an Activity - both knowledge of how to do the Activity efficiently and effectively, and also ancillary knowledge gained during execution. Both these forms of knowledge may be as important to your organization and to its clients as delivery of the expected outputs.

However, most organizations make a poor job of capturing, maintaining and re-using this knowledge, for several reasons. This is mainly because context is critical - without this, you get information (which just has a maintenance cost) rather than knowledge (which also has a business value).

The way forward is to ensure that you define, execute and manage Activities in such a way that knowledge, both execution-related and ancillary, is automatically captured and maintained. This is what HIM process modelling provides.

A HIM Activity has well-defined inputs and deliverables, but these can be updated during execution. The final Activity along with all its inputs/outputs are preserved as part of the Plan, which not only provides a human-friendly audit trail that forms a useful part of the knowledge base of the organization(s) concerned but can also be used as a template for future work.

A HIM Activity is a place to record not only the outputs expected by management, but also the way you produced them and any supporting artefacts - all in its proper context. This is a very different thing from the pure task-based approach of traditional project planning and workflow definition.

More about Activities in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management, Knowledge Management | No Comments »

The new process modelling - Activities

Monday, October 17th, 2011

In th next few posts, I will look at Activities in HIM. For now, I’d like to offer regular readers of this blog a (hopefully thought-provoking) question to mull over.

In most descriptions of business processes, Activities are described as a means of converting inputs to outputs, optionally with the aid of supporting resources and under the control of business rules. But are the stated outputs all that arises from an Activity? In other words, is there something else that is there after doing it, that wasn’t there before?

Answer in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management, Knowledge Management | No Comments »

The new process modelling - improving processes

Friday, October 14th, 2011

At this point in the series on the new process modelling, it might be helpful to have a reminder of why it is important.

For each piece of work, do you do the same tasks, in the same order? Do you create the same documents and data? Do you work so perfectly that there is no room for improvement?

Most people do not find it helpful to describe their work processes in terms of task sequences or concrete outputs, so lack a means to determine the true structure of their work, agree it with colleagues, then manage it to increase productivity, contribute more to organizational goals, and streamline their work with partners.

Time and motion studies on knowledge workers in the US show that that this problem is a very expensive one. They spend an average of 28% of their working day organizing their interactions with one another (rather than doing useful work). The cost of this wasted time to employers, and hence to the US economy, is estimated to be 650 billion dollars per annum – i.e., a cost to the worldwide economy of something like 2 trillion dollars.

However, even this figure is an underestimate. The true impact of poor human interactions is not just on efficiency, but also on effectiveness – on how well people align their work with the tactical and strategic goals of their employers. As an example, further research shows that although 82% of all organizations are undertaking some form of change initiative at any one time, 70% of change initiatives fail.

The underlying cause is that management science was not invented to deal with human collaboration – it was invented to deal with manufacturing. Current management thinking, and hence current software collaboration tools, are based on the “Scientific Management” of Frederick Taylor and Henry Ford. This task scheduling and approval approach fails to deal with the modern collaborative workplace. To manage knowledge worker interactions, we need a new management science: Human Interaction Management, or HIM.

HIM is based on 5 simple principles, which are also the basis for a software tool called a Human Interaction Management System, or HIMS. The reference implementation of a HIMS, HumanEdj, empowers people to take control of their own work, do it better, and work in a structured way with colleagues from other organizations.

HumanEdj does not compete with other workflow or collaboration tools. Rather, it unlocks the true value of such tools by providing a way to use them in higher-level, manageable Plans. HumanEdj is the missing link that organizations need to join up their collaborative work, to extend it to partners, and to improve it over time.

In the next post, I’ll return to the details of how to model processes using HIM. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management, Productivity | No Comments »

The new process modelling - how Roles help you maintain processes

Thursday, October 13th, 2011

I entered the IT industry in the mid-1980s, at a time when developers were just starting to transition en masse from procedural to object-oriented languages. Some people saw the advantages immediately, but others found it hard to get their heads around the new approach. In particular, some developers found it difficult to understand what programs that were made of objects would actually do. Where did they start? Where did they end? And what happened in between? It seemed so much easier to design and maintain systems when you had a single procedural control flow.

The truth, of course, is exactly the opposite. Object-oriented programs are much easier to design and maintain, which is why very little software development, even in the small scale, is now procedural - mainly *nix shells (which haven’t changed much for decades) and a few other specialized scripting languages.

But why are OO programs easier to design and maintain? Because they separate concerns, by grouping together the code and the data that addresses a particular area of interest. You can then deal with each area in isolation - for example, you can monitor the functionality and performance of each area, and adjust it as required. For example, you can deal with exceptional cases that crop up by specializing the object’s type definition (typically by adding a sub-class) to change its actions or content in certain situations.

This is part of what Roles in a HIM process give you. Unlike swim lanes, Roles are true objects, so they can be used as templates for new objects. The last post showed how this can be used to duplicate Roles within a Plan. It can also be used to make new, customized versions of a Role to deal with special situations, either during execution of a live Plan or when preparing a template for a new Plan.

A simple and common customization is to introduce new documents or data into a Role, that can be done at any time either by the owner of the Plan or the player of the Role as part of a Stage. This information is automatically shared with everyone else in the Stage.

Another common customization is to alter the scheduling of the Role’s activities. Like Stages themselves, Activities in HIM are not one-off steps in a control flow, but have a status that is set collaboratively, and may be returned to as needed. To manage this, each Activity is given an estimated number of days effort, a start date and a deadline. This scheduling information is then used to manage the Plan.

For example, the HIMS will warn you if an input to the Activity looks unlikely to be ready in time for it to complete on schedule. The Plan can then be adjusted in various ways - to declare the input ready for use when it is only partially complete, to remove the input from the Activity altogether, or to adjust the scheduling information assigned to the Activity.

It is also common to make such adjustments when preparing to start a new Plan - for example, if the template usually used for a particular type of work process would result in a cost that in this case is too high.

By contrast, if you are using BPMN, the UML, S-BPM or any other procedural process definition technique, it is not even visible how data and documents drive the process forward, and the options for adjustment are both more limited in scope and more complex to implement.

More about OO process modelling in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management | No Comments »

The new process modelling - adding people to a process

Wednesday, October 12th, 2011

In my last entry about object-oriented process modelling, I described HIM Roles and started to explain why they are nothing like swim lanes in procedural notations such as BPMN and the UML.

In this post I’ll look at another crucial difference. This one may have you wondering how you ever managed to use procedural process notations in the first place.

Taking an example at random, let’s suppose you are describing a process for creating a series of marketing brochures. One key player in this process is a graphic designer, responsible for creating the fonts, colours, images, and so on that are used in the brochures. Now let’s suppose that the deadline for publication is brought forward, which results in there being too much work for the graphic designer alone. You need to bring in another graphic designer. How can you do capture this using (for example) BPMN?

The short answer is that you can’t. There is no simple way to duplicate a swim lane, and even if you manage to do so, it is almost impossible to share work between the new swim lane and the old swim lane in a natural way. This is because the procedural approach is based on tasks carried out in order - as described in my last post, the swim lane itself only exists to group its tasks. There is nothing in a BPMN diagram to represent the people that do the work, or how they share its inputs and outputs.

By contrast, in a HIMS such as HumanEdj, all you need to do is copy the graphic designer Role, and assign to the copy to a different person. The new Role immediately has access to all the same information as the old Role, since it belongs to the same Stages. By default, the new Role also has a copy of each Activity in the old Role - this can be left intact, on the assumption that the Roles will negotiate informally which items of work to carry out (they may, for example, work together on all brochures) or alternatively, some Activities can be deleted from each Role to partition the work more precisely.

More about OO process modelling in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management, Management, Requirements | No Comments »

The new process modelling - Roles are not swim lanes

Tuesday, October 11th, 2011

People new to object-oriented process modelling often confuse HIM Roles with swim lanes in procedural notations such as BPMN and the UML. This is an easy mistake to make, since at first glance, both appear to be a way of assigning people (or machines, or organizations) to tasks.

This is exactly what a swim lane is. However, a Role in HIM is not this at all, but rather a set of responsibilities. Taking on a Role in a HIM Plan means accepting those responsibilities - and you may wish to decline.

Taking on a Role also means that you get what you need in order to fulfil its responsibilities:

Understanding of the goals to which those responsibilities pertain (the Stages in which your Role is included);
Membership of the appropriate teams (the other Roles in those Stages);
Structured communication channels with those teams (Messages sent within a Stage);
Definition of the expected Deliverables (defined as part of your Activities in each Stage);
Access to the Resources required to produce them (the inputs to your Activities in each Stage).

A Role is much more than a way to group tasks - it has purpose, behaviour and content. In particular, your Role actually contains data and documents (or more likely, links to data and documents stored in enterprise systems), and you may well add new data and documents to it as you do the work required to meet its responsibilities. A Role is therefore also a mechanism for creating, sharing and maintaining knowledge.

More about Roles in the next post. In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Governance, Human Interaction Management, Productivity | No Comments »

The new process modelling - more about Stages

Monday, October 10th, 2011

In this blog series, I am describing a new, object-oriented approach to process description, that dispels the “Coordination Fog” around workplace collaboration (see Peter Denning’s columns of March and September 2011 in “Communications of the ACM”).

Project management and workflow systems treat collaborative activity as sequences of tasks, which is unhelpful for understanding its purpose and structure, and systems for analyzing communications history provide no means to design, manage and improve collaboration.

By contrast, Human Interaction Management (HIM) draws on research in multiple disciplines to propose that successful human collaboration is based on 5 principles - effective teams, structured communication, use of knowledge, use of time, and collaborative planning - and the HIMS lets you describe a collaborative work process as a set of related objects. Rather than focusing on the order in which activities are carried out, HIM planning, forecasting, monitoring, and improvement focus on objects of business interest such as goals and their resource usage.

One such object of business interest is the Stage, which represents a set of related goals. in previous posts, I described Stages and some of their properties. Here I will give a real-world example that illustrates how unhelpful it is to try and define real-world collaborative work by putting activities in a pre-defined order.

Let’s consider a process for what in the jargon is called Complex Sales - i.e., not buying something from ebay, but rather the work by a product/service supplier to turn interest by an enterprise client into a realized sale. A typical HumanEdj Plan for such work might include the following Stages:

1. Record Lead - for example, update CRM with the details of a lead
2. Qualify Lead - assess whether or not it is worth pursuing the lead
3. Create Opportunity - obtain the client’s requirements
4. Develop Opportunity - devise a solution for the requirements
5. Negotiate Proposal - work with the client to agree a way forward
6. Prepare Provisional Delivery - while waiting confirmation, start putting in place arrangements for solution delivery
7. Close Opportunity - act on confirmation or rejection of the proposal

Here are some key observations.

First, each Stage has different people involved (including in some cases, the client) - i.e., the Roles that take part in each Stage are different. Hence, grouping work by Stages not only makes it clear who you are working with, and why, but provides a way to group communications - in other words, messages sent within a Stage go to all and only the people playing Roles in that Stage. No more need for complicated, wasteful CC and BCC lists.

Second, it is unlikely that the Stages wil be carried out neatly in order. As anyone who has ever helped put together a sales bid knows, it will be sensible in some cases to jump about between Stages, return to “previous” Stages, omit certain activities, and so on. This is the natural way of working in HumanEdj, but means jumping through artificial hoops in a workflow or project management system.

Third, Stages mean that it is possible to plan, forecast, monitor, and improve work using in HumanEdj via objects of business interest (such as goals and their resource usage) rather than misleading and superficial characteristics of a process (such as the order in which tasks are carried out). This is a huge boon to managers.

There are many more advantages than this to the Stages mechanism. However, for now that is probably enough. In my next post, I will describe Roles in a HIMS, and how they are in fact nothing like swim lanes.

In the meantime, if you would like to try HumanEdj, visit http://rolemodellers.com/get_started to register for an account on the demo Web instance.

Posted in Business Process Management, Human Interaction Management | No Comments »