How to Develop A Specification for Designing a New Process

MML's approach to developing a design specification is set out diagrammatically below.

It has a practical rather than theoretical basis, having developed out of recent assignments where we have helped clients:

• articulate their vision of the new process, in terms of:
  • a high level "picture" of how the overall process works;
  • the principals and concepts around which the process is to be designed;
  • the policies to be applied in routine execution of the work prescribed by the process;
  • the objectives and performance targets the process is to deliver;
• build in best practice and capitalise on advances in technology;
• deliver substantial bottom line benefit.

Even in companies that really understand the physical design processes well, designing business processes is relatively poorly understood. Engineering companies, as a typical example, recognise that most new products start life as a design concept and outline brief. Initially this may be little more than a sketch accompanied by a few notes on the overall size, performance and function of the product. However, the outline will usually evolve to become a fully developed design brief before serious amounts of time are spent developing the detailed technical design. This approach to designing "physical" things is well understood and commonly applied by business to most new products.

Sadly no such well-developed process is yet commonplace for the design of business processes. Part of the problem is that processes are not tangible, so those involved think the physical approach does not apply. Too many companies embark on the task at a detailed level first, without stopping to consider what the overall design parameters are.

We believe this is one of the major reasons why so many process-reengineering projects have proved disappointing. The approach we have developed overcomes this problem. By emulating the physical design methods that have already proved their worth, it provides structured tools to help produce a fully functional design specification. Success can be demonstrated by clients who have used our approach to produce robust process designs quickly.

Putting together the design specification is usually the responsibility of the senior team, often the board. It assumes there is a well understood business imperative driving the need to redesign, as well as a project sponsor who is part of the senior team.

The following sections briefly describe the key elements.

Before work can start on the development of the design brief the team must share a common language and understanding. In particular they need to have a reasonably detailed understanding of the underlying principles and concepts of the business tools and techniques they want to be built into the management of the business, through the process.

This is an essential key to avoiding delays in the development of the specification. It can be costly in terms of time and money to divert the whole of the senior team to debate and clarify their understanding of a particular technique, such as Supply Chain Management.

Depending on the process to be designed it is usually possible to assess the individual levels of understanding from a questionnaire. Gaps will need to be filled through some form of education.

The high level process design is the equivalent of the “artists impression” in the physical design process. Its purpose is to provide a one page “picture” of the main flows of activity and decision making within the process, linking the key elements together in a relevant sequence.

It will define the scope of the process by showing what is to be included, and where it links to other processes, by definition outside the scope. At this stage the design is focused solely on process and is independent of organisational structure. The most efficient and effective processes tend to be produced by a design approach where functional responsibilities and information requirements follow from the process design, supporting rather than constraining it.

The policies that are set and the way they are observed will have a direct bearing on the design of the process and will impact how well it works. They form a fundamental building block of the design specification.

Our structured approach means each policy is expanded to give a full interpretation of its definition. It groups policies into:

• systems and information;
• operations;
• responsibilities;

The mechanism for defining the policies seeks to expand the “policy statement”, by spelling out its implications, both for the implementation of the process and for the day-to-day operation of the business.

For example, if the policy is to give customers reliable delivery dates, amongst other things it will be necessary to:

• include a capacity management function, to avoid overloading capacity and thus quoting unrealistic dates;
• include a means of agreeing priorities should demand exceed supply capability, as an day to day management issue, to avoid conflict between sales and production.

In this way it identifies specific functional requirements that will be placed upon the team responsible for the detailed design. It also serves to highlight some of the conflicts that may well arise in the application of the policy. By exposing them early on we can build resolution into the process and clarify the day-to-day responsibilities the board have for ensuring the policies are observed. It can be used as a source of reference for monitoring the management of the policies post implementation.

We all understand that physical products are designed to meet specific performance targets, whether it is fuel consumption for a car or processing speed for a computer. In the same way, for the business process to perform, those responsible for the detailed design must know what the performance targets are. These targets are defined within the business objectives and, like the policies, form a key element of the design specification.

To help the design team these objectives must be defined in a measurable way. To be relevant to the overall design they must deliver the business objectives associated with the original imperative for change. It is therefore essential to structure these targets in a hierarchy, starting with the overall business measures and then defining the lower level supporting measures on which the overall performance will depend. We normally find three levels of decomposition sufficient.

For the senior team to have confidence in the detailed design the design team must be able to explain how the process they have designed will deliver the target performance measures. The design brief must therefore define the way in which the targets are to be measured.

Where a process is being reengineered it is vital that there is a reasonably comprehensive understanding of the current process. Care must be taken not to waste time trying to produce an ever more precise definition of exactly what happens now. However, without some form of current map there is a real risk that one or two vital elements of the current process could be overlooked.

Our experience indicates that it is often the exception handling that makes business processes convoluted and complicated, or the interfaces between functions where processes break down. Having a formal map of the current version ensures that critical activities are identified and allows the gap analysis to be done. Current processes are most easily and efficiently mapped using one of the modern notations developed specifically for the purpose, such as Role Activity Diagrams or RADs.

Understanding the shape of the business is an essential precursor to developing a practical and realistic design for the new process. Often we find clients have a limited understanding of the different factors that drive the business. Without a quantitative and qualitative knowledge of their relative importance and the impact they have, it is almost impossible to conceive of how they might be best accommodated by the new process.

The business analysis provides outputs including the demand and cost drivers as well as the current performance metrics. In this way it provides the base information used to develop the vision and the business objectives. It also provides useful input to the gap analysis.

Steps 2, 3 and 4 above usually develop from a two day workshop with the senior team. The output provides the majority of the input to the design specification. Comparing these requirements to the “As Is” process definition and the output of the business analysis enables critical gaps to be identified between the current state and the desired state.

These are collated in the form of a checklist and provide a useful reference for the design teams, enabling them to check that the new process they are developing in detail fills the gaps.

The degree to which it is desirable to build these elements into the new process varies, depending on the imperative behind the initial process concept developed by the senior team. Nevertheless, it is usual to find that companies want to make a step change in the cost and/or performance of the process and therefore these two elements become key.

Methods for gathering this information include:

• literature surveys;
• management education courses;
• benchmarking surveys, both inter and intra sector;
• external advisors;
• supplier and customer visits.

Costs and timescales will vary and it is often useful to include an assessment of the extent to which this information is needed in the initial questionnaire before embarking on what can be an expensive undertaking.