The Telework Process Framework

This is the second piece of my collaboration with Nikos Michalakis, VP, Software Platform at Toyota Research Institute Advanced Development and it also appears on his Red Vest Mindset site.

As companies continue to adjust their work practices due to the pandemic and extend the adoption of telework, industries such as transportation, retail, hospitality, real estate and several others continue to be negatively impacted. This is particularly evident in urban areas. At the same time, there exists a growing demand for structured and scalable approaches for creating telework-centric business processes. In this piece we present the Telework Process Framework that is used for maximizing the tasks that can be performed via telework in a process. The Framework provides a structured and scalable approach for organizations to define a new telework-centric process, as well as to restructure/retrofit existing processes to introduce or increase telework.

The Telework Process Framework consists of three stages: Creation, Optimization, and Standardization. For some processes, this 3-stage sequence (shown in Figure 1) is performed in short order, takes a few iterations, and requires little investment. For others, it may take several years, many iterations, and require substantial investments. The Framework is used by Process Teams, permanent cross-functional teams that include domain, human factors, employment, financial, and agile development experts, along with engineers from various disciplines that form their own best practices and objectives. 

As we had stated in our first post a process defines how a team does work. A task defines what work is done. A process consists of a set of tasks that must be performed in a particular order. A task receives input and through a collection of activities that utilize/access the input and a set of resources produces an output. The performance of the team employing the process is evaluated using a variety of metrics. 

The Creation Stage

A new telework-centric process (the Target Process) is created because an organization wants to solve a problem consistently, and reliably on a repeated basis while maximizing how much of the process can be performed using telework, assuming that the process cannot be completely automated from the beginning. The goal of the Creation Stage is for at least some of Target Process’s tasks, or even parts of a task to be performed via telework. During the Creation Stage the Process Team performs the steps shown in Table 1. 

For example, let us assume that the Process Team must define a new process for the daily maintenance of a fleet’s autonomous vehicles (AVs). The Process Team defines the four tasks shown in Figure 2.

For illustration purposes and in order to understand how the steps presented in Table 1 are applied by a Process Team we provide the detailed definition of task T_TP1 in Figure A1 of the Appendix. 

By applying the telework environment and productivity conditions we determine that, as defined, task T_TP1 incorporates telework, but cannot be performed entirely via telework. However, according to the exit criterion stated above, since at least one part of a non-automated task can be performed via telework, the Process Team can proceed to the Optimization Stage.

If the Target Process does not incorporate any telework when it is first defined, then the Process Team can continue experimenting with the process definition by repeating steps CS2 and CS3 while the process starts being applied. While, and iterating through various task definitions, and associated resource combinations in an attempt to introduce tasks that can be performed via telework, the Process Team works closely with the teams using the Target Process in order to observe their performance and incorporate their feedback into the process. The number of iterations will be dependent on the organization that is performing the Target Process and the investment amount allocated for the process creation. Finally, notice that the difference between creating a new telework-centric Target Process and refining an existing process with the intent of introducing telework is exhibited in step CS2.

The Optimization Stage

While during the Creation Stage the Process Team may not know how much of the Target Process can ultimately be performed via telework and how effective the teams performing the process will be if they telework, as the Target Process is applied repeatedly, the understanding of each task improves. Equipped with this understanding, the Optimization Stage’s goal is to maximize how much of the Target Process can be performed via telework while maintaining a high employee performance level. This can be done either by expanding the activities that can be performed via telework within a task or by introducing telework to additional tasks within the Target Process. The Process Team accomplishes this goal in three steps by identifying similarities between the Target Process and a set of processes that have previously been optimized for telework, using these similarities to transform tasks in the Target Process, and finally generalizing each transformed task and the tasks used as the basis for these transformations into a single optimized task. As soon as at least one task of the Target Process has been transformed and generalized the Process Team can move to the Standardization Stage. 

During the first step, the Process Team identifies all previously defined processes that include tasks that are similar to one or more of the Target Process tasks and are either performed via telework or have been entirely automated. This is called the Related Processes Set. Identifying similarities and determining the acceptable degree of similarity between two tasks is domain-specific and must be defined by the Process Team. For example, the Process Team may require that before two tasks can be considered similar, all of their Activities must be similar.

For example, assume that the Related Processes Set includes the process called ADAS Vehicle Serviced at Auto Dealer. An ADAS vehicle assists the driver in operating the vehicle safely, whereas an autonomous vehicle doesn’t have a driver. As shown in Figure 3, the ADAS Vehicle Serviced at Auto Dealer process consists of five tasks.

This process was included in the Related Processes Set because task T₁₂ is considered similar to task T_TP1 since Activities b, c, d of task T_TP1 are considered similar to Activities a, b, c of task T₁₂. Moreover, task T₁₂ is performed entirely via telework thanks to the vehicle’s Connected Diagnostic System technology. For illustration purposes we define task T₁₂ in Figure A2 and show the similarities between tasks T₁₂ and T_TP1 in Figure A3 of the Appendix.

During the second step, the Process Team determines which of the matched task’s activities that are performed using telework can be used as a basis to transform the corresponding activities in the Target Process task. In our example, activity a of task T₁₂ will be used as the basis to transform activity b of task T_TP1 to enable this activity to be performed via telework. But to be able to perform activity b of T_TP1 via telework, the Process Team realizes that it must perform a transformation. Instead of physically removing the Parked Vehicle’s hard drive (activity a of T_TP1) it will need to make the autonomous vehicle’s Data Storage System remotely accessible. This means that activity a of T_TP1 will need to be eliminated and two new activities (corresponding to activities e and f of task T₁₂) will need to be added to task T_TP1.  The challenge with this transformation is that an AV produces an order of magnitude more data than the ADAS vehicle and 90% of it is not valuable. Consequently, uploading everything will be prohibitively slow. For this reason, the Process Team also incorporates different tools (adds to the vehicle a cellular modem enabling remotely connecting to the vehicle’s data storage system, and includes a GPU enabling data filtering while eliminating the need for the technician). With these transformations, the Process Team has increased the cost for the data transfer but decreased the overall amount spent on personnel compensation. The transformed task is called T^’_TP1 (shown in Figure A4 of the Appendix) and can now be performed 100% via telework.

While in this example the Related Processes Set included only a single process and only one task from this process was used to transform a task in the Target Process, in other cases the Related Process Set may include numerous processes and several tasks from these processes may be similar to a single task in the Target Process. In those cases identifying and executing the appropriate transformations will be more tedious and complex. We recommend that the Process Team stays agile and try small task clusters first, rather than trying to identify the perfect Related Process Set.

During the third step, the Process Team tries to determine whether the similarities between the transformed task of the Target Process and the corresponding similar task from the Related Processes Set can be generalized into a single task (the Generalized Task) thus providing further optimizations (and reuse as we will show in the Standardization Stage). In our example, by considering the similarities in tools, skill sets, and objects used by  tasks T₁₂ and T^’_TP1, both of which can now be performed one hundred percent via telework, the Process Team determines whether and how these can be generalized. The result of this generalization is task T_G1 that can be used by both the Target Process and the process called “ADAS Vehicle Serviced at Auto Dealer”. The detailed definition of task T_G1 is shown in Figure A5 of the Appendix. 

Figure 4 depicts how task T_G1 replaces the corresponding tasks in the Target Process and the process in the Related Processes Set.

Also during this step, the Process Team assesses the appropriateness of the task-specific skill sets identified during the Creation Stage and determines which skill sets need to be removed entirely as part of the performed transformations, which need to be upgraded, and which can be downgraded. Finally, the Process Team refines the metrics of the Target Process’s performance and re-evaluates the investment that will be necessary to scale this process. We designed the Optimization Stage steps in this way to encourage the Process Team to remain agile and jump back and forth between Creation and Optimization via multiple small iterations rather than trying to figure out everything upfront before making progress.

The Standardization Stage

As the performance and scalability of the optimized Target Process continue to improve additional organizations within the same company begin to adopt it. Each organization may implement it differently based on the investments they can make, the tools at their disposal, and the skill sets they possess. As a result of such constraints, they tend to make adaptations specific to their environment and needs. The goal of the Standardization Stage is for all organizations (potentially spanning multiple geographies) using the Target Process to employ a consistent set of tools and skill sets, and achieve consistent performance particularly for tasks involving telework. As soon as at least one group of tools, skill sets, and technologies have been standardized across enough organizations within a company to have an impact on a company’s telework strategy then this stage is effectively complete. In many instances, standardization could last several years particularly if the Target Process is adopted by many organizations across several industries.

As a first step in the Standardization Stage the Process Team catalogs the tools, and skill sets utilized by the various organizations employing the Target Process within the company, as well as the appropriate performance data. For example, assume that the Target Process called “Daily Maintenance of Fleet AV” was originally developed by the company’s Japanese organization, and is now being used by its US and German organizations. Further assume that for this process’s optimized and generalized task called “Retrieve Vehicle Data” that is performed via telework the Process Team collects the data shown in Table 2:

By examining the collected data the Process Team determines:

1. The number and type of organizations that adopt the Target Process, as well as the  speed by which the process is adopted ;
2. Any variability in the skill sets used by each organization;
3. Meaningful differences in the achieved performance;
4. Changes to the percent of the process that is performed via telework in each organization;
5. Cost implications of the different implementations.

The intent of this evaluation is a specification of the skill sets, the tools, and the various types of interfaces (software- and hardware-based, or otherwise physical) that will be adopted by every organization within the company using the Target Process. Such specification drives the training necessary to attain the requisite skill set and establishes the performance and cost parity among the organizations adopting the Target Process while maximizing the percent of telework within this process. It also drives the companywide investment that will be necessary for the Target Process to be standardized. For example, the data management system used in the “Retrieve Vehicle Data” task could be standardized to AWS because it’s available globally. Alternatively, and for a less costly standardization option, each region could adopt an open-source container-based system like Kubernetes to standardize the interface used by the DevOps engineers handling the data uploads. 

Once the tools and skill sets are adjusted, the performance metrics of the Target Process are further refined. As a result of these refinements in tools, and skill sets a more consistent performance of the process is typically observed. Moreover, using established collaboration best-practices it becomes easier to further scale the Target Process, as well as train more people that will be performing tasks via telework. This training and education do not have to stay within company borders. With multiple companies adopting the Telework Process Framework and each Target Process there will be opportunities to create various forums to exchange best practices amongst Process Teams. Over time several industries may adopt the Target Process at which point it becomes a regional or global standard that can be used as a building block for further Creation. 

Standardization provides a huge opportunity for innovations that support telework transformation. These innovations can come from multiple third parties including large corporations, startups, and academia.  Market opportunities open up when incentives align at a large-scale. It would be more likely for a startup to get funding to pursue a product or a team to open source a solution and leverage outside contributions when Process Teams across companies openly seek solutions that can be reused by multiple organizations/geographies within their companies. 

Conclusion

To date performing a task or an entire process via telework was the result of accidental observations and actions, or corporate cost-cutting measures. The Telework Process Framework provides the steps on how to think about telework proactively, taking into account improved efficiency, higher product quality, or employee well-being, and plan it in a way that can be used in more processes and by more organizations within or outside a company while increasing the probability of success every time it is employed.

Previous article in the series

Appendix

The generalized tools, skill sets, and objects are shown within <>. For example <VehicleClass> would be “Autonomous Vehicle” or “ADAS Vehicle”.