Build and Test | Process and Technology

There are two main alternative approaches to this stage and it is important that you choose the right approach for your circumstances. The first approach is prototyping; that is, the incremental configuration of elements of the systems solution followed by testing with the users followed by further iterations of fine-tuning. This process is repeated for all elements of the systems solution. The second is a full build against a detailed specification or blueprint followed by full system testing.

One advantage with the first approach is that the HR and business users get the opportunity to see and feel HR self-service quite early in the build process. This serves to maintain momentum and enthusiasm and helps to match expectations against system delivery. The main disadvantage with this approach is that it can take longer unless it is tightly managed — the temptation can be to continue with minor refinements rather than to end that element of the solution and move on to the next.

In the case of the second approach, the main advantage is that you have better control of the costs and schedule and at the end of the build you have a more complete solution. But there is less possibility of making changes during the build and after it is delivered any changes will be more expensive. There is a heavy reliance on the quality of the detailed specification that the system configurers are using.

During this stage, there is a greater distinction between the technology- and the process-related activities than during the detailed design stage. Even with the prototyping approach, the system configurers are primarily focused on the technology build and system test activity. The HR and business users, however, should be primarily focused on operating procedure definition, training course preparation, development of user security profiles, test script development and user acceptance testing. The methodology and programme plan provide the means of linking the process and technology (and people) streams here. The interdependencies and 'touch points' are closely aligned through this even though the team members may be working on their own specific tasks.

The change management theme of course continues. The change leaders mobilised during detailed design perform the next iteration of impact and readiness assessments, often at the local functional or site level, and initiate the resulting actions. The change focus should not be restricted to the line areas; HR must be preparing for this change. There is an important link here with the capabilities work, as HR needs to get ready to let go of much of the transactional work and begin to focus on what the business partner role really means and how they will equip themselves for this. An excellent way of bringing this to life is the use of 'conference room pilots' where the business and HR users of Web-based HR technology adopt their new roles in a controlled environment, testing how the new roles, process and system fit together in a simulation of the new environment.

Conference room pilots provide a good example of how wider involvement in the programme activities can be achieved and there is greater opportunity during this stage to use involvement in the programme activities as an action to promote awareness and commitment. Typically, involvement from HR and the business in defining operating procedures, preparing training course material and particularly user acceptance testing, make the programme 'come alive' for many. One area that provides excellent opportunity for involvement but is often neglected is that of data cleansing and preparation. This involves checking the validity of existing data, mapping it to the data required in the new system and creating any additional data fields that are not present in the current systems. Involvement in this can be achieved across all employees in the organisation as they are requested to check and validate their own individual employee record data. This is a very powerful approach to moving the perception of the HR transformation programme from concept to reality.

Useful tool for mapping and redesigning process

A useful tool for mapping and redesigning process is 'brown paper'. An overview is developed in the 'As Is' processes, these are sketched onto large pieces of brown paper, as demonstrated in Figure 1.\

 
Figure 1: Example brown paper.

A workshop is then convened with HR and, where appropriate, representatives from the line where the process is debated and challenged. This also involves identifying for participants the extent to which the proposed HR technology can automate and change different tasks. Attendees at the workshop then redraw the existing process, identifying strengths that they wish to retain and sketching out improvements to the way that participants interact and the way the information flows through the process. A new brown paper is produced from the workshop as demonstrated in Figure 2.

 
Figure 2: Example brown paper.

There are a number of issues that need to be taken into account when building a brown paper:

• Disagreement about how the process is performed is OK. It is probable that different people perform the same process differently; that is, a significant finding. Try to capture both and get agreement on future processes.
• Not knowing the answer to every question is OK. In the process of asking questions needed to identify the flow, it almost always happens that a question will be asked that no one can answer and people can be tasked to get an answer.
• Have specialists on hand who can answer questions about what can and cannot be achieved using the HR system. Participants may come up with solutions that cannot be delivered by technology. It is best that these issues are addressed in the workshop so that participants can design processes that can be delivered and you do not have to ask participants to keep redesigning processes in later workshops. If this is not done, having lots of unanswered questions about what the system can and cannot do, will result in a process that is so high level and has so many questions that it needs more design work after the workshop or further workshops have to be convened.
• Ask for hard copy and complete examples. All key documents should be obtained with 'live' information, if possible. Ask for a printed copy of significant computer screens if the function is 'online' or interactive between the user and system.
• No value judgements (yet). The process of creating the initial brown paper should be a fact-gathering exercise. The evaluation of the information comes later. At this point, all ideas are good ideas.
• Identify one stream of activity and do it start to finish: then integrate other streams with it. Experience has shown that participants may become confused when trying to understand and document several different flows simultaneously. By choosing one and taking it start to finish, similarities and differences can more readily be identified, and the meeting more easily controlled.
• Write explanations directly on the brown paper. The only paper attached to the brown paper should be 'live' documents and their adhesive note critiques.
• Be challenging, do not fall into the trap of merely refining existing processes and responsibilities and essentially promoting the status quo. HR transformation is about shifting from today to tomorrow. Therefore, when reviewing processes, question whether HR should be involved in a task and how that involvement adds value.
• Capture the impact on the line and employees. Where HR is removed from tasks and where the line will use self-service, it is important that this information is captured and detailed. This understanding of how responsibility for process changes is vital for moving to the next stage in the change process, that of determining the impact of the new processes and systems on the organisation and the readiness of the organisation to adopt them.

Overview of the key steps in mapping HR processes

Overview of the key steps in mapping HR processes, summarising key actions and outputs.

Step	Activity	Tools	Output
Define the Target Process	Define key HR activities as processes Prioritise key processes Break processes into manageable chunks Identify and document key process variations Involve subject matter experts	Brainstorming, customer focus groups	Prioritise reengineering efforts
Develop 'As Is' Models	Conduct workflow analysis (who does what when, where, how) and identify handoffs Audit existing constraints in systems (e.g., compatibility, integrity, and consistency of data) Determine problems in current process from customer's and administrator's perspectives Identify key measurement related to process (e.g., cost, quality, time, rework, etc)	Workflow analysis, activity analysis, systems audit, focus groups, interviews	Flow map of existing processes and their performance in terms of cost and quality
Challenge underlying assumptions	Challenge each activity in the current process (why is it done, why is it done there, why is it done then, why does that person do it, why is it done this way etc) Challenge current policies, practices and philosophy Explore alternative delivery methods Cut across functional silos Incorporate and leverage information technology	Visioning, scenario building, brainstorming, critical thinking	Identify opportunities for radical improvement
Develop 'To be' Models — Identifying where and how technology will impact the process	Solicit information from broad base about alternatives Benchmark other companies Integrate separate processes Take detailed design of new information systems Draft new process flow Assess potential impact of new process (cost/benefit, risk etc)	Benchmarking, conflict resolution, issues resolution, simulation, consensus building	Design new processes, select best information technology to support process, determine impact of new processes
Implement, Roll out, Market	Implement incremental approach Conduct pilot testing Implement systems integration Market the programme, create curiosity, implement trial use Offer training to support users Manage resistance Anticipate and address morale problems	Marketing, communication, training, coaching, experimentation	Facilitate the smooth migration to new system and user's acceptance of the new processes
Measure BusinessImpact	Capture business impact of HR processes before and after reengineering Measure business impact, not just budget and milestones in programmes and activities Separate short- from long-term impact	Activity analysis, cost analysis, customer service survey, focus groups	Monitor progress and impact

Figure 1: Source— based on recognised models from a variety of consulting firms. 

Detailed Process and Technology Design

Through envisioning, defining the service-delivery approach and building the business case, the HR transformation solution will have become ever clearer. Careful consideration will have been given to the people, process and technology elements such that the overall solution is one that will deliver the vision and benefits targeted. The first stage of implementation, therefore, is to finalise the design at the detailed level.

Detailed design follows the principles of the systems mindset by considering the multiple linkages between elements of the solution, working from the whole solution to the details of the constituent parts. By utilising this and the target benefits, those charged with developing the detailed process and technology design can begin.

During business case definition, the technology solution that best fits your specific needs will have been identified. The task in detailed design is to specify the configuration of this technology solution right down to the level of the system screens on which the transactions are performed. The main decisions that need to be made at this stage are the following:

1. Which elements of the process will be performed by the system and which elements need to be performed outside of the system?
2. Which data fields must be completed in order for the process to work and which are optional?
3. Can the technology solution be configured to support the new processes without needing to modify the underlying code or programming of the system? Often this is termed the 'vanilla' system. Modification over and above the 'vanilla' system means that additional implementation and maintenance costs will be incurred. If thebusiness benefits can be delivered with the 'vanilla' system then clearly this is the ideal route. If this is not the case then the costs (including maintenance costs) of making the modifications need to be weighed against the reduction in benefits if the modifications are not made.
4. In the case of global or multinational implementations, are there local country or regional differences that need to be addressed? Ideally these should only be local statutory differences as these should already be 'pre-configured' in the technology solution. Any additional differences will need to be developed and maintained separately. In a similar way to the 'vanilla' system debate above, modifying the system for local requirements adds to both the initial implementation and the ongoing maintenance costs.

The decisions around detailed design are usually made in workshops with HR and the line, or by the HR and line representatives on the programme team. Involvement of HR and the line is crucial in this process as it provides both a check that what is being designed is pragmatic and workable and that those who will need to operate the new processes and systems are engaged to promote commitment.

As the detailed design proceeds, where resolution on particular design issues cannot be achieved through the workshops or the programme team, it may be necessary to take some of these decisions to the steering board for direction. This 'design authority' role is one that the steering board should play by exception but it can be critical particularly in providing guidance and direction on the degree of customisation or local variation.

From a process design perspective, the main task at this stage is to map the processes onto a diagram that shows what the system will do and what the responsibility of HR, managers, employees or external agencies will be.

Process Workstream | Programme Governance Tools

The person responsible for the process workstream is the person who will effectively manage the process re-engineering work to ensure that in the 'new world' HR processes become as lean and efficient as possible. There are a number of ways of approaching this. One way, for example, would be to approach the work with literally a clean sheet of paper, calling upon various people in the organisation to contribute their view of a particular process and constructing the new process from scratch.

Whilst this has undeniable benefits in terms of creating a perception of inclusion, by engaging a wide stakeholder audience and appearing to be genuinely in line with the concept of meeting customer expectations or being customer driven, there are also a number of potential major pitfalls with this approach. One such pitfall is that, having created or crafted a new process based on this highly inclusive clean sheet approach, it then becomes eminently obvious in consultation with the technology department that to configure such a process in the system would require considerable time and expense. This realisation then might prompt the need to go back out to the stakeholders who contributed to the original process to say that it is no longer applicable — with the subsequent dissonance this would create.

Another way of doing it would be to adopt as a baseline the standard 'out of the box processes' that come with the new system, and only permit variants to those standard processes where it can be demonstrated that a significant business benefit would result. These variants may take the form of observance or compliance with legal requirements, or where a judgment could be taken that for cultural reasons it is necessary to do things in a particular way and that enormous disaffection could be caused by overhauling or retiring that particular process.

One of the drawbacks of presenting baseline core processes in the way described is that it could appear to senior stakeholders to be a fait accompli and might therefore create a backlash from stakeholders, with associated disruption to the programme.

On balance, therefore, it is probably the best tactic in most situations to engage the appropriate stakeholders on process grounds by presenting the overall picture. In other words, to explain that whilst their views are being sought to help refine and better the existing processes, there are nevertheless frameworks within which those betterments or changes need to take place to take account of the issues surrounding configuration within the main system. These issues carry a cost implication now and in the future.

Process Consulting Mindset

Before describing in more detail what a process consulting mindset is, it is perhaps fitting to start with a statement of what it is not. The word 'process' has been popularised in management literature in the past decade, and has become mainly associated with business process re-engineering/work process redesign. Re-engineering of HR processes is certainly going to feature as one of the HR transformation work streams. But this is not what we mean by 'process consulting' or the development of a 'process consulting mindset'.

'Process consulting' is a term first coined by Edgar Schein and is about the way we bring about change. A process is a sequence of steps that leads to an outcome. Process consulting is about working with clients step by step through a change process. This involves taking account of new realities/information at each step and adjusting tactics accordingly.

The change tools/frameworks mentioned in the 'System mindset' section can help to shape this process. For example, the change equation is a good tool to use with stakeholders to develop a shared view of 'where we are now' and to identify the next practical steps that will best ensure progress. This means that those involved in the work of HR transformation (both internal and external consultants) must engage purposefully with their critical stakeholders. HR transformation is a collaborative effort, and when there are questions, concerns or resistance these must be properly dealt with rather than swept under the carpet. There is no place for those involved in leading work streams doing change to people.

Looking specifically at HR transformation, the relationship that the HR transformation programme team must establish with its internal clients should have the following goals in mind:

• engage in actions (with individuals or groups) that are most likely to promote successful change;
• establish a collaborative relationship;
• work to solve problems in a way that they stay solved;
• ensure that attention is given to both technical and relationship issues;
• develop internal client commitment;
• think constantly about how you can best deliver value.

To achieve this, it is necessary to work with clients through a change process. The HR transformation programme team brings tools, models, frameworks, and technical know-how to the table. But the ownership must remain with the clients.

How is this Achieved?

First, by bringing our knowledge and expertise to the table in ways that enable our clients to make decisions, rather than presenting them with a fait accompli.

Second, by not remaining bound by the original plan. Regardless of how much time we may have invested in agreeing on the future vision for HR and developing an implementation plan with our key client stakeholders, the reality of change is that the unexpected happens and we need to make adjustments to reflect whatever new reality we now face. Change is not achieved through a business version equivalent of 'painting by numbers'.

Third, by focusing on the next practical step within the context of the overall programme goals (building on the change equation, 'in the light of what we now know, what is our most purposeful next step to get us from where we are now to where we want to be?').

A process consulting mindset also accepts that resistance to change is natural and seeks to surface it and work with it, even if embracing resistance appears to slow down the programme. A process consulting mindset also recognises that there will be multiple interests and that it is necessary to invest in building a strong coalition (but not absolute consensus) around a change vision.

Features of the process consulting mindset that we will refer, and which help us to achieve the above, include the following tools:

• The use of a straw man to engage people in decision-making. This means making a proposal that is robust enough to stand with credibility, but not so robust that it cannot be tested and potentially pulled apart and reconstructed. One of the main benefits of using a straw man is to surface opinion and issues so that areas of agreement are identified and disagreements resolved. We have found that the use of the straw man is a very effective way to accelerate decision-making.
• The use of workshops to engage people in key discussions and decisions. Often preceded by one-to-one meetings, workshops nevertheless have great value (and are time efficient if well structured) in bringing key stakeholders together to work through issues and make decisions. (Although a convenient way of getting time in diaries, one-to-one meetings alone will not lead to purposeful dialogue and collaborative working.)
• Adopting a facilitation role with key stakeholders: working with groups; being able to present information in ways that will engage key stakeholders; surface issues/resistance and areas of agreement; and mobilise to take the next step.

Let us look at an example of a process consulting approach in practice. There are often very different stakeholder perspectives on what HR transformation means. Even within the HR function, there can be considerable distance between people on how technology will be used; the contribution HR professionals should make; which HR activities should be in-house or outsourced; how to develop new skills and capabilities in HR professionals, etc. 

The approaches we will describe show that investing in a process that engages people in conversations about critical questions about HR transformation early on (and throughout) is fruitful, productive and necessary. So a process consulting approach recognises a situation of multiple perspectives and co-creates a process with stakeholders to work through these perspectives. This approach builds checks and balances into the way change is implemented, allowing those leading the transformation to accelerate or slow down in ways that ensure stakeholders remain committed.