PulseCheckForm — Virtual Operations

Sign Up

Forename

Forename cannot be blank. Upper and lower case letters only.

Surname

Surname cannot be blank. Upper and lower case letters only. Hyphens and Spaces are allowed.

Company Name

Company Name cannot be blank

Email Address

Email Address cannot be blank and must be valid email address

Telephone

Job Title

Job Title cannot be blank

Industry

Industry cannot be blank

Business Area

Business Area cannot be blank

Opportunity Identification

Process Scoping

Objective:Opportunities identified follow a standard scoping process. Any changes to scope are tracked through a governance structure

We do not scope processes when we are analysing them. Any change to scope is approved or rejected by the project team automating the process We scope processes as we analyse them, but requirements can be missed. Scope changes are approved or rejected within the automation team We have a standardised scoping process. Automation team review scope changes and have authority to approve or reject changes We have a standardised scoping process. Defined project stakeholders review scope changes and have authority to approve or reject changes When we initiate a new project, lessons learnt from similar past projects are reviewed where scoping issues occurred, to mitigate a repeat event

Process Targeting

Objective:Processes targeted for automation align to business objectives and any broader digitisation strategy

We do not have automation objectives to direct process targeting We do have automation objectives, but they are not aligned to the objectives of the business area(s) being targeted for automation We do have automation objectives that are aligned to the objectives of the business area(s) being targeted for automation We do have automation objectives that are aligned to the objectives of the business area(s) being targeted for automation and support an overall digitisation strategy We regularly review automation and business objectives to ensure continued alignment to an overall digitisation strategy

Process Analysis

Objective:Process analysis ensures the process is a suitable candidate for automation and the benefits being targeted are deliverable

We do not analyse processes in a structured way We analyse processes on an opportunity-by-opportunity basis We analyse processes in a standard way and the outputs are reviewed by stakeholders who sign them off We analyse processes in a standard way using templates to assist stakeholders in reviewing outputss We analyse processes in a standard way using industry techniques (e.g., six sigma, lean) to ensure comprehensive analysis

Solution Design

Objective: Rigorous solution design is critical to optimise the value that automation can deliver to business teams

We do not have a formal solution design process. A developer creates the solution and there is no review of it by other stakeholders We have a formal solution design process, but it is rarely followed. The developer completes solution design, which may be reviewed on request We have a formal solution design process. The design is signed off by the business team and subject to change control We have a formal solution design process. The design is signed off by the business team and a broader set of stakeholders to ensure no conflict with other issues and is subject to change control Our solution design process is frequently reviewed. Stakeholders from critical functions collaborate to improve solution design

Project Team Set Up

Objective:Opportunities identified follow a standard scoping process. Any changes to scope are tracked through a governance structure

We do not scope processes when we are analysing them. Any change to scope is approved or rejected by the project team automating the process We scope processes as we analyse them, but requirements can be missed. Scope changes are approved or rejected within the automation team We have a standardised scoping process. Automation team review scope changes and have authority to approve or reject changes We have a standardised scoping process. Defined project stakeholders review scope changes and have authority to approve or reject changes When we initiate a new project, lessons learnt from similar past projects are reviewed where scoping issues occurred, to mitigate a repeat event

Project Management

Project Structure

Objective:A defined project structure outlines the stages within a project, ensuring all critical elements are covered in a governance structure

We do not have a defined project structure for automation projects We do have a defined project structure that outlines each stage of an automation project, but this may not always be followed We do have a defined project structure that outlines each stage of an automation project that is known to everyone and is followed consistently We do have a defined project structure that outlines each stage of an automation project that is known to everyone and is followed consistently and can be modified for new or different scenarios, subject to agreement We do have a defined project structure that is regularly reviewed and updated to create new best practice

Total Project Cost

Objective:Tracking of delivery and estimated ongoing run cost is a critical component of an automation program to ensure expected ROI is achieved

We do not define project budgets or estimate ongoing operational cost We do set project budgets and ongoing operational costs, but targets are consistently missed We set project budgets that are monitored, and operational cost is estimated ahead of deployment and monitored on-going We do set project budgets that are monitored and are consistently accurate, and operational cost is estimated ahead of deployment and monitored on-going We review project budgets and operational costs after each project and adjust parameters and thresholds for future project accuracy

Risk & Issue Identification

Objective:Process analysis ensures the process is a suitable candidate for automation and the benefits being targeted are deliverable

We do not analyse processes in a structured way We analyse processes on an opportunity-by-opportunity basis We analyse processes in a standard way and the outputs are reviewed by stakeholders who sign them off We analyse processes in a standard way using templates to assist stakeholders in reviewing outputss We analyse processes in a standard way using industry techniques (e.g., six sigma, lean) to ensure comprehensive analysis

Project Stakeholder Communication

Objective:Communicating with key stakeholders throughout the project lifecycle, ensuring they are aware of activities, deadlines and actions.

We do not have a defined communication plan for each automation project. Project managers communicate with stakeholders as required We do not have a defined communication plan for each automation project, but each project does report progress We do have a defined communication plan for each automation project which is followed according to guidelines We do have a defined communication plan that includes templates for all core communications We do have a defined communication plan that includes templates for all core communications that are updated following review of each project

Change Management

Objective:Change management is critical to ensure teams are supported through the transition to new ways or working or job removal

We do not have a defined change management approach for training or supporting the move to new ways of working when automation is deployedWe do not have a defined change management approach for training or supporting the move to new ways of working when automation is deployed We do not have a defined change management approach for training or supporting the move to new ways of working when automation is deployed and any change management activities, including training or changes to ways of working, is organised and delivered by the business We do have a defined change management approach that requires change management requirements to be documented ahead of deployment and delivered by the business We do have a defined and templated change management approach that requires change management requirements to be documented and included in the project plan ahead of deployment and delivered by the business We do have a defined and templated change management approach that requires change management requirements to be documented and included in the project plan ahead of deployment and delivered by the business, supported by relevant functions (e.g. HR)

Delivery

Automation Operating Model

Objective:Defining the organisation and governance that supports delivery of your automation program, aligned with digitisation strategy is essential

We do not have an organisation design or service model for the delivery of automation services across the organisation We do not have an organisation design or service model for the delivery of automation services across the organisation but there is a group responsible for automation delivery We do have an organisation design or service model for the delivery of automation services across the organisation, but it has no authority to deliver automation in a defined way We do have an organisation design or service model for the delivery of automation services across the organisation that ensures automation is delivered with appropriate standards and quality We do have an organisation design or service model for the delivery of automation services across the organisation that is continually reviewed and adapted to changing automation requirements

Delivery Lifecycle Control

Objective:Assurance around the delivery of automation to live is critical to ensure the business and operational teams have stability

We do not have delivery lifecycle controls used across the organisation We do have delivery lifecycle controls used across the organisation, but they are frequently missed We do have delivery lifecycle controls used across the organisation. New automations cannot be deployed without conforming to the necessary controls We do have delivery lifecycle controls used across the organisation with responsibility for compliance assigned to an automation oversight team We do have delivery lifecycle controls that are frequently reviewed and updated to ensure they evolve along with best practice

Development Practices

Objective:Development of bots and the underlying practices ensures a robust solution is built.

We do not have standard development practices. Developers build bots in the way best known to themselves. We do have standard development practices, but these are rarely followed. We do have standard development practices, practiced by developers but not by all stakeholders We do have standard development practices, known to and practiced by all stakeholders We do have standard development practices that are frequently reviewed and updated to ensure they evolve along with best practice

Technical Design

Objective:Strong and considered technical design gives a robust solution that can be followed through into build and ultimately into Live

Our technical design is the responsibility of the developer with no third-party review of the proposed solution Our technical design is the responsibility of the developer with informal third-party review of the proposed solution Our technical design is the responsibility of the developer with formal review of the proposed solution by systems and applications application owners Our technical design is the responsibility of the developer with formal review of the proposed solution by systems and applications application owners and walk through with business owners and functional SME’s Our technical design approach is frequently reviewed and updated to ensure it evolves along with any new systems and applications

System Stability

Objective:Rigorous solution design is critical to optimise the value that automation can deliver to business teams

We see greater than 20% system exception rates frequently We see between 10% - 19% system exception rates frequently We see between 5% -9% system exception rates frequently We see between 3% - 4% system exception rates frequently We see a maximum of 2% system exception rates frequently

Support

Support Bot Utilisation

Objective:Ensuring licence cost is delivering the highest return for the investment is core to a sustainable automation program

We do not set bot utilisation targets. Bot utilisation is not actively tracked, monitored, or reported against We do not set targets for bot utilisation, but it is reported against. Spikes and troughs are investigated by the automation support team We have defined utilisation targets for bots. Tracking, monitoring, and reporting of utilisation is built into the governance structure We audit our bots to understand their utilisation. Pool utilisation and capacity management are optimised We use heat maps or similar to analyse our schedules to ensure bot utilisation is scheduled to its optimum

Support Scalability

Objective:As the number of processes in production grows, the capability of support needs to scale to match the requirements to ensure success

We do not have a structured support framework for live bots Our support team has a framework. This includes things like a severity matrix and incident resolution SLAs, but it is not followed Our support team has a framework. This includes things like a severity matrix and incident resolution SLAs. These are constantly followed Communication procedures are followed to make stakeholders aware of issues and activities being taken to resolve the incident We review bots, systems and applications to identify potential failure points. When we identify potential failure points, they are escalated

Change Development Standards

Objective:Development of changes to bots and the underlying practices ensures a robust solution is built

We do not have change development practices We do have change development practices, but they are rarely followed We have standardised change development practices in place, known to everyone To build our change development practices, we frequently review and update them to ensure they evolve along with best practice Supporting our change development practices, to mitigate errors code reviews are performed frequently throughout development.

Change Delivery Control

Objective:Assurance around the delivery of change is critical to ensure the business and operational teams have consistent stability

We do not have change delivery controls We do have change delivery controls in place but are frequently missed. Control evidence could be missing, incomplete or incorrect We have a standard delivery control framework that is known to everyone. Checks completed before deployment to make sure all of the controls have been passed Our change delivery controls are owned by a team / committee with the responsibility of ensuring the process is followed We also include support functions (e.g., HR or L&D) approval in the change delivery controls to ensure a complete review of change

Process Exceptions

Objective:When a bot cannot complete a process, it can severely impact a team’s capacity planning and ultimately the ROI

Bots generate process exceptions greater than 75%, frequently Bots generate process exceptions between 50% - 74%, frequently Bots generate process exceptions between 25% - 49%, frequently Bots generate process exceptions between 10% - 24%, frequently Bots generate process exceptions less than 10%, frequently

Benefits Realisation

Benefit Ownership

Objective:Each automated process has defined ownership for the realisation of benefits

We do not have formal ownership for benefits realisation We do not have formal ownership for benefits realisation, but it is implicit in the handover to the business We do have formal ownership for benefits realisation, and it is explicit in the handover to the business We do have formal ownership for benefits realisation, and it is explicit in the handover to the business who have been involved in the benefits definition throughout the project We do have formal ownership for benefits realisation, and it is explicit in the handover to the business who have been involved in the benefits definition throughout the project and are required to report progress against the benefits target to track the overall automation benefits

Initial Benefit Identification

Objective:Identifying and quantifying the potential benefits of each automation project at the analysis stage facilitate the creation of a robust business case and prioritisation of projects

We do not have automation objectives to direct process targeting We do have automation objectives, but they are not aligned to the objectives of the business area(s) being targeted for automation We do have automation objectives that are aligned to the objectives of the business area(s) being targeted for automation We do have automation objectives that are aligned to the objectives of the business area(s) being targeted for automation and support an overall digitisation strategy We regularly review automation and business objectives to ensure continued alignment to an overall digitisation strategy

Benefit Sustainability

Objective:Automation is used to help sustain adaptability and maintain cost baseline and deliver growth or additional activity operations without increasing the cost baseline

Our automation program does not track the benefits of automation with stakeholders Our automation program has an understanding of the benefits being delivered by automation through occasional, informal stakeholder reviews Our automation program has regular reporting of the ongoing realisation of benefits. We have frequent communications with stakeholders to understand ongoing requirements Our automation program has regular reporting of the ongoing realisation of benefits and engages with stakeholders who are formally incentivised to achieve the benefits, to understand ongoing requirements Our automation program has regular reporting of the ongoing realisation of benefits and engages with stakeholders who are formally incentivised to achieve the benefits, to understand ongoing requirements and to develop ongoing strategies for further automation

Stakeholder Communication

Objective:All stakeholders affected by automated projects are informed appropriately throughout the life cycle of each project

We do not have regular or formal communication on the automation program to stakeholders We do have informal channels for communicating with some or all impacted stakeholders concerning the automation program We have regular, standardised communications with some, or all stakeholders associated with the automation program We have regular two-way communications with all impacted stakeholders through the automation program Stakeholder communication regarding automation is formally embedded in all impacted teams which result in the scalability and broadening of automation

Long-Term Stakeholder Commitment

Objective:All stakeholders (business functions, technology, process owners) affected by automation projects are aware of their ongoing role(s) in the continued progress of the wider automation program

We do not work routinely with automation program stakeholders to look for new automation opportunities or problems to resolve We expect automation program stakeholders to identify new automation opportunities and engage with automation program management We collaborate across automation program stakeholders to identify new automation opportunities and assess ongoing benefits from existing automation The automation program fosters long-term relationships with process owners and business functions to anticipate and identify process changes, building a pipeline of automation opportunities The automation program has formal reporting and review process to engage with process owners and business functions to anticipate and identify process changes, building a pipeline of automation opportunities