Gig Economy

As stated in a previous blog post, Service Level Agreements (SLAs) with clients are key elements of business process management and must be supported by the project management system.  Another important element of managing field service projects is establishing and tracking appropriate SLAs with Field Service Representatives (FSRs) and/or associated contracting companies.  While the primary field service company responsible for the project carries all the risk in meeting the contracted client’s SLAs, key tools, procedures, best practices, and system capabilities are needed to manage that risk when using a gig-workforce.  Also, key elements of system integration will be needed to track operational effectiveness against the contracted SLAs.

Client SLA Types and Attributes –

The project management system must be able to capture key SLA attributes from the contract with the client.  This implies that the SLA definitions in the contractual agreement must be detailed enough to provide the necessary attributes for tracking, reporting on compliance, and billing.  We define SLA Types as formulations and/or measurements used to evaluate whether contractual objectives are being met.  We define SLA Attributes as the elements, triggers, and constraints used in support of the formulation for the target SLA.  

Example Client SLA Types:

• Turn-Around Time (TAT) – max. time taken to complete a task(s)
• Average Turn-Around Time (ATAT) – average time taken to complete tasks 
• Response Time – max. time required to respond to a work-order request 
• Average Response Time – average time required to respond to work-orders 
• Abandonment Rate – not to exceed percentage of work-orders abandoned while waiting to be completed
• Time to Assignment – time from request received to its assignment 
• Time Service Factor (TSF) – percentage of tasks completed within a definite timeframe
• Task Completion Rate – tasks completed/timeframe, objects built/timeframe, …

Example Client SLA Attributes:

• Location/Time Zone for SLA Time Reference 
• SLA Units of Measure  
• Task Property for SLA Start Trigger
• Task Property for SLA Complete/End Trigger
• Days/Times of Effective Operation (e.g., operating hours of business that effect SLA calculations) – examples: 6am-5pm, Monday-Friday, 8am-12pm Saturday.
• Exceptions to Days/Times of Effective Operation (Periodic and Absolute)
• SLA can be paused during non-operational hours: Yes/No

An integrated project management system to support emerging field services using a gig-workforce should have the capability of capturing a wide range of client SLA types and client SLA attributes and be able to handle the formulations needed to calculate, analyze, report, and bill for SLA performance.

Managing FSR SLAs –

To adhere to the laws defining how a company can engage contractors or field service representatives (FSRs) to maintain their 1099 tax reporting relationship, the level of detail used to assign and manage that contractor’s or FSR’s activities is limited.  Also, the types and number of incentives that can be leveraged to ensure meeting project objectives (e.g., client SLAs) are also limited.  Therefore, the drafting and management of service levels with FSRs or related entities can be a challenge.  In general, a project management company can only contract a project’s start and completion dates/times with an FSR.  The company cannot manage the FSR’s scheduling of their individual activities in support of that assigned project’s completion.  The project management company also must be careful on how they might incent the FSR to complete the project early, increase their productivity, and/or deliver higher levels of quality.  Obviously, after working with FSRs over time the project management company can target those FSRs that deliver the highest productivity, quality of work, and are the most reliable.

There are several approaches a project management company can use to incent an FSR’s productivity, work quality and/or reliability.  The first is to give the FSR the flexibility to select which contracted completion date/time they wish to accept, which would come with a predetermined payment for that project or task.  Typically, the earlier the completion date/time selected by the FSR, the higher the compensation for that work.  The same could be done with contract selection options for productivity and quality measures.  Note that if the project management company can get FSRs to select the higher productivity contract options, their risk in delivery to the Clients SLA is lower.  But there is a trade-off between lowering risk, lower margins, and higher customer satisfaction.

Another approach is to score an FSR’s performance for each contract.  Productivity, quality, responsiveness, and reliability metrics can be leveraged to evaluate an FSR’s long-range performance.  As an incentive, these long-range performance metrics could be made visible to the FSR.  This awareness will provide a clear understanding of how the FSR can improve their performance, receive more job opportunities, and increase their income potential.  For reasons of privacy and to avoid defamation lawsuits, it is advised that no performance scoring is provided on social media or to other companies.  But the project management company could validate a performance score that is provided by an FSR to another company as a reference to their work history.

Given the variations of state and federal laws, care must be taken when implementing any system that contracts with FSRs and attempts to incent their performance.  But project management companies that leverage the gig-workforce must find ways to reduce their risk, maximize their performance, and optimize their business results in the face of delivering to complex and varied client SLAs.

Service Level Agreements (SLAs) and Key Performance Indicators (KPIs) are key elements of business process management (BPM). While SLAs and KPIs are closely related and provide insights into specific performance measures of a business, they have clearly different scope and intent. Also, SLAs and KPIs can be difficult to define, measure, and achieve when using a gig-workforce to deliver field services. The laws and regulations used to define how a business engages a gig-worker (1099-NEC tax reporting status) and the type of work involved in the delivery of field services can make establishing and accurately tracking SLAs and KPIs difficult.

Service Level Agreements (SLAs) – 

Wikipedia defines SLA as “a commitment between a service provider and a client…(where) aspects of the service – quality, availability, responsibilities – are agreed” (https://en.wikipedia.org/wiki/Service-level_agreement).  In other words, an SLA is a written agreement that qualitatively and quantitatively specifies a service commitment between a business and its client. SLAs usually define units of performance measure and penalties for failure to meet those measures. SLAs are set to measure, evaluate, and compensate for future service performance. SLAs can include standards for timelines, quality levels, and/or the amount of service a client expects from the field service provider. In addition, SLA metrics allow clients to track real-world needs of their businesses and are usually set by the client for the field service business to meet.

Key Performance Indicators (KPIs) – 

KPIs are measures that define the progress with respect to a strategic goal or objective. KPIs are used to measure past performance and whether the business is meeting expectations relative to growth, revenue, ROI, profit margin, or other decision-making criteria. KPIs are usually set to evaluate whether a business is meeting its strategic goals and what areas need to be addressed to improve its performance. 

Using SLAs and KPIs – 

As mentioned, SLAs and KPIs are closely related, but clearly different. An SLA is forward-looking, while KPIs focus on past performance. SLAs set benchmarks for you to measure performance in the future. KPIs will measure the performance of your business against strategic business benchmarks as time passes. KPIs are set based on strategic goals and objectives, while SLAs are near-term performance metrics that can directly impact a business’s operation or abilities. SLAs are used to establish expectations (usually via a contractual agreement) for service delivery by another vendor, while KPIs are used to self-evaluate success or failure towards specific goals and objectives.

Main Elements of an SLA –

• Business Objectives: objectives to be achieved in the provision of the services.
• Target Services: description of service deliverables.
• Performance Metrics: performance standards expected by the client.
• Reporting Mechanism: mechanism for periodic reporting of performance metrics.
• Compensation Credits and Remediation: compensation formula that incentivizes for exceeding performance metrics and penalizes for failure to achieve performance metrics.
• Change Control and Contract Management: mechanism for periodic review and change to the service levels over the course of the contract.
• Grounds for Termination: conditions that give the right to terminate the contract where performance standards fall consistently below an acceptable level.

Managing SLAs when using a Gig-workforce –

Establishing and tracking SLAs in field services delivery can be challenging. A field service business, and its project management team, cannot manage a group of “1099 contractors” the same way they manage the company’s employees. The differences associated with managing contractors versus employees can present interesting challenges to the project manager, especially in relationship to tracking and achieving certain SLAs. Given a project manager can only provide a gig-worker with start and complete-by dates/times for a given workorder or project, it is difficult to track incremental progress and/or fine-grain elements associated with the work. Therefore, the project manager has a difficult time determining where a project or workorder is against a specific SLA. 

The other challenge is developing a project management system with sufficient flexibility to support a wide variety of SLAs. Common components of an SLA include response time, time to complete service, quantity, completion percentage, quality levels, failure rates, times of operation, exclusion dates, etc. Providing a simple interface to allow project managers the ability to input complex formulas with abstract variables that can be tracked, analyzed, invoiced, and reported back to the client has proven to be difficult.  The variety of projects inherent in field services, and the complex constraints often placed on the time and location of the service, makes it almost impossible to cover all possible SLA descriptions. In most cases either the project management system covers a limited number of project or work-order types, and/or a person must implement a customer specific tool (usually a software application or interface) that implements a formula that matches the SLA description. This “application” pulls relevant project/work-order performance data from the project management system in real-time, and reports to the client, and billing/invoicing system, to what level the performance objectives were met. Therefore, the cost to a field service company to implement, track, and report SLAs can be significant. 

Present State of SLA Implementation in Field Service Project Management Systems –

At present few, if any, project management systems can support the wide variety and complexity of SLAs associated with field service delivery using a gig-workforce. Some project management systems attempt to provide sufficient APIs to allow external applications to retrieve relevant data in support of calculating and reporting on SLA performance metrics. Dashboarding of these performance metrics is important to the project management team and often requires yet another application to be leveraged. Therefore, an integrated system to support project management of a variety of field services and their related SLAs would significantly improve operational efficiency and scale of a field service business that leverages a gig-workforce.

There have always been Gig-workers: actors, artists, musicians, consultants, salesmen, real estate agents, handymen, etc.  There are several reasons why the gig-economy continues to grow. 57 million US workers in 2018, approximately 36% of the US workforce, appear to prefer freelancing over full-time employment, primarily since it provides them with greater flexibility and independence.  Estimates are that 87 million US workers will be participating in the gig-economy by 2027.  Non-traditional employment, particularly through gig economy platforms, enables individuals to pick their own hours, place of employment, and clients.  Firms also can benefit from using a gig-workforce through more efficient management of expenses, increased access to a higher variety of skills, and better management of resources via on-demand staffing.

There are three main factors which are driving the growth of the gig-economy: 1) the need for businesses to better manage resources to match business demands, 2) workers wanting more control of their work schedule for a better pay and work/life balance, and 3) technology which enables real-time remote coordination and management of work.  Even though working in the gig economy offers a lot of freedom and flexibility, workers in the rapidly evolving gig-economy are finding they face new challenges.  To broaden the expansion of the gig-economy into the field service industry, corporations must leverage new technologies, management platforms, and processes to manage projects, as well as offer access to “human services” to support the needs of a gig-workforce. 

Workforce Advantages and Challenges of Gig-Economy

Advantages:

• Flexibility – Research shows that 70% of freelancers say the main reason they do gig-work is to attain better work-life balance, with 60% saying their working conditions are flexible.  This allows the gig-worker to work when they want, how long they wish, where they want, and on the jobs they are most interested and comfortable doing.  This flexibility also provides ability to engage in continued education, certification, and licensing activities.  The Gig-worker can specialize or become multi-functional.
• Independence – Gig-workers have a sense of “working for themselves” versus working under a management system and/or for a company.
• Variety – Gig-work provides the workforce access to a variety of job options, which can help workers avoid boredom and be energized in their ongoing job activities. The Gig-worker can control their own destiny and develop their own interests while taking advantage of incremental opportunities where they live and work.
• Pay – Gig-work often yields a higher pay rate than regular employment status would provide.  The Gig-worker directly benefits from their productivity and skills and are not “held-back” by others.  Also, surveys show that 19% of gig-workers use gig-work as extra income.  Pay can also change more rapidly based on demand and skills availability versus traditional periodic pay raises for regular employment positions.  Finally, gig-workers have the freedom to choose what jobs they wish to work and can select the pay level they see is most competitive.
• Tax Deductions – The Gig-worker is essentially a business and can deduct legitimate business expenses and make investments in tools: vehicles, computer, hand tools, etc.
  

Challenges:

• Benefits – Gig-workers often must identify their own sources for health insurance, retirement plans, 401K, IRAs, life insurance, and matching contributions to a savings plan.  54% of independent contractors have no access to benefits through their employer or group coverage plan like a professional association; 40% can only get medical insurance for themselves if they’re married to someone who has it.
• Taxes – No tax is deducted from the worker’s pay to cover federal or state taxes.  The worker is responsible for paying their taxes quarterly to avoid penalties at the end of the year.
• Isolation – Often limited to no regular contact with other workers.  No sense of community or cultural solidarity, normally provided to employees who meet regularly in an office building, manufacturing, or warehouse environment.
• Potentially Inconsistent Income – Gig-work income is not guaranteed (like a traditional job with hourly wages) and can fluctuate depending on available assignments and the ability of the worker to identify opportunities. 
• Limited Guidance – Most gig-workers are independent contractors and do not have the benefit of a manager, project lead, or peer employee to continually provide advice and/or teach them how to work efficiently.
• Stress, Burnout, Exhaustion – Gig-workers must find their next gig or deal with frequent changes to their present assignments.  Gig-workers are not provided a guarantee of continued work or of new assignments once the present job is completed.  Gig-workers can also face rapid changes in salary.
  

Addressing Challenges Faced by the Gig-Workforce

• Access to Benefits – Companies contracting with a gig-workforce could provide access to health insurance plans, retirement plans, 401K and IRA plans, life insurance plans and membership in group travel discounts (hotels, rental cars, airlines, buses, etc.).  Other benefits include access to therapist, counselors, and coaching.
• Worker-to-Worker Engagement – Provide a specialized social media platform for Gig-workers to engage with each other and discuss common challenges and best practices found to complete and/or support assignments.  This also allows a medium for the workforce to discuss issues of stress, finding jobs, pay, and general work/life challenges.
• Access to Training/Continuing Education – Companies and academic organizations can provide programs and support for gig-workers to gain additional training, certifications, licensing, and other skills development resources, increasing the capacity and capabilities of the gig-workforce.
• Tax Management Tools – Provide the gig-worker access to tools and automated deduction from pay to help estimate and pay their taxes.
• Job Portal – Provide a job portal to expose gig-workers to job opportunities across an industry, a region, and/or an expertise.  
• Transparency in the Project Management Platform – Enable the workforce to see all available projects and their related work activities, both completed and in process.  Allow workers to engage with each other to share best practices, challenges, helpful tools/apps, skills requirement, and other items that would benefit them in their support of a project.  Finally, allow the gig-worker to sustain a record of their skills, experience, accomplishments, and job performance, which can be used to support access to future opportunities.

Note that there are many challenges and opportunities in expanding the use of the gig-workforce in the delivery of field services.  With the development and deployment of the right technologies, tools, programs, platforms, and processes, workers and companies can benefit from enablement of the gig-workforce to deliver field services.

References:

The Gig Economy by Edison Research: http://www.edisonresearch.com/wp-content/uploads/2019/01/Gig-Economy-2018-Marketplace-Edison-Research-Poll-FINAL.pdf

Gig Economy by PYMNTS.com: https://www.pymnts.com/wp-content/uploads/2019/04/Gig-Economy-April-19.pdf

Global Gig Economy by Mastercard: https://newsroom.mastercard.com/wp-content/uploads/2019/05/Gig-Economy-White-Paper-May-2019.pdf

Gig Workers in America by Prudential: https://www.prudential.com/wps/wcm/connect/4c7de648-54fb-4ba7-98de-9f0ce03810e8/gig-workers-in-america.pdf?MOD=AJPERES&CVID=mD-yCXo

State of Independence in America by MBO Partners: https://s29814.pcdn.co/wp-content/uploads/2019/06/MBO-SOI-2019.pdf

Definition: A Workflow is a sequence of tasks, with a set of objectives, to support processing of physical and/or data objects to achieve a set of goals.  Workflows are the flow of actions and decisions describing how something gets done.  Managing a list of unconnected tasks is not a workflow.  Workflows have tasks that are dependent on others in the workflow to achieve a unified goal or objective.  Three types of workflows may be built by workflow management systems, the use of which is dependent upon the needs of the project. These include sequential workflows, state machine workflows, and rules-driven workflows. 

• A sequential workflow is linear and progressive, like a flow chart. This workflow goes from one task or process to another and does not step back in the sequence.  This category of workflows includes “process workflows” where the tasks are predictable and repetitive.  Examples: expense report approval, employee onboarding, invoicing and billing, kitting, simple surveys.
• A state machine workflow is more complex than a sequential workflow and may step back in the sequence if a dependency mandates. These workflows go from one “state” to another “state” via an event-driven set of operations.  Examples: inventory management, software development, equipment or process testing.
• A rules-driven or case workflow is essentially a higher-level sequential workflow.  “Rules” determine the workflow progress. They use conditions to decide if expressions are “true” or “false,” and the rules are modeled with the “if,” “then,” or “else” expressions.  Moving through a rules-driven workflow depends heavily on the constraints and/or conditions associated with the work (who, what, when, where, …) and the choices made throughout the workflow (selection from the available options to proceed).  Examples: break-fix work-orders, support tickets, insurance claims, surveys.

Note that most workflows to support field service activities are either sequential or rules-driven workflows, but state machine workflows must also be supported by the project management system.  Also, the workflow design and management component of an integrated project management system must be able to support the creation of highly efficient and effective workflows of all types.  

Workflows can be human-centric (most tasks are performed by a human) or system-centric (most tasks are performed by a machine).  Most field services require a human-centric workflow.  Human-centric workflows are more difficult to design given the need to avoid errors induced by human judgement, decision making, and mistakes.  System-centric workflows, if designed properly, should be much less error prone, require little to no quality control, and be much more reliable in their operation as long as the data used in support of the workflow is consistent in the bounds and formats expected.

The workflow engine in a project management system should “automate” the transition from one task to another and not require human intervention to continue processing of the workflow.  The project management system, with support from the workflow engine, should automatically handle notifications, reminders, triggers, transitions between representatives/systems, reports and other key transitions between major stakeholders supporting the workflow.

Some best practices in workflow design:

• Get input from all stakeholders (executive management, project management, field service representatives, QC’ers, analytics team, reporting team, client, accounting, etc.) on the key elements, goals, objectives, expected outputs and other key features of the target project.  Also, support workflow design reviews and regular workflow audits with stakeholders (or when recurrent issues are identified).
• Insure the ability to “take action on data”, e.g., data analytics, in support of maximizing productivity, exposing issues, and identifying new business opportunities.  
• Enable “ease of optimization” upon feedback from stakeholders.  Workflows must be easy to manage and change.
• Employ principles that enable a positive user experience including responsiveness, intuitive forms layout, consistency across workflow components, clarity of interface actions, and specificity of what is expected.
• All data entries should be in standard units of measure.  Drop-down menus, picklist, or “spinners” can be used to minimize the number of possible entries.  All data entries should be checked against an expected format, range, or allowable values at the time of entry.  “Free-text fields” should be used on an exception basis only (requires approval by a review committee).
• Workflow forms should be mobile friendly (given most field service data entry is performed with a mobile device).
• Target alignment with database structures, backend dash-boarding, and analysis objectives.
• Support integration and/or data compatibility with target electronic document management system.
• Represent the workflow using a visual aid, flow-chart, or flow diagram.  If the diagram becomes too complicated to understand, the design is probably also too complicated.
• When possible, split workflows into sub-flows or modules. The use of smaller, more digestible modules result in greater efficiency, quicker issue resolution, easier testing, and overall better workflow performance.  Also, a modular design enables addition or removal of new features or processes more efficiently.
• Think of workflows as non-linear processes. Workflows are designed to enable you to return to previous steps seamlessly without causing bottlenecks or lag time. 
• The use of workflow templates designed for specific types of projects and/or work-orders can help minimize the time required to implement a new field service project and allow reuse of a “known good” workflow designs.
• Make sure you can measure productivity using key points in the workflow as indicators of progress.

There are many other best practices in workflow design.  The above are just a few of the key ones identified from many years of experience.  The art of workflow design can be made more systematic by good design practices and clear understanding of a project’s goals and objectives.

Coordination

Field service projects, and their associated work assignments, often require coordination of multiple field service representatives (employees, independent contractors, gig-workers, etc.) performing related and associative tasks in parallel.  The data collected and/or created in support of performing and executing workflows often occurs while the field service representative is working offline from the company’s project management system and databases.  Offline operation is required necessary given poor connectivity in many field service locations and often requires the storage of large datasets on the field service device.  Enabling the workforce to perform work in parallel is key to minimizing the amount of time, cost, materials, and resources required to complete a project.  But this “concurrency of work” with its related transaction processing and data collection may create issues in correctness in the data representing the measurements, status, and resources associated with the project.  The project management system, the workflow engine, and the workflow design must support and take into account concurrency of activities and maintaining accuracy in the information associated with the measurements, status and resources of the project.

Critical vs. Non-Critical Operations

Workflows can be broken up into sections of “critical or dependent” operations and “non-critical or independent” operations.  Critical operations may share data objects and/or resources with other parts of the workflow, have dependencies on other operations before they can complete, and/or affect other operations in the workflow.  Non-critical operations in the workflow imply they can be performed at any time, independent of other actions in the workflow.  To avoid a “race condition” (https://en.wikipedia.org/wiki/Race_condition) and maintain correctness in the data objects and workflow operations, a property of concurrency control called “mutual exclusion” must be used.   Mutual exclusion ensures that if a section of the workflow is already performing an operation on an object (e.g., critical section) no other section of the workflow is allowed to access or modify the same object until the first operation has finished and released the object for other operations to occur.  The requirement of mutual exclusion was first identified and solved by Edsger W. Dijkstra in 1965 “Solution of a problem in concurrent programming control”, Communications of the ACM, Vol. 8, No. 9.  

Workflow Design

Enabling the ability to execute a workflow offline from the main project management or database system and using multiple field service representatives working independently and in parallel on critical sections of the workflow, makes the workflow design challenging and places special functional requirements on the workflow engine.  

• This is especially true if you also wish to minimize the time to completion (e.g., optimize efficiencies) of the project.  Serializing all tasks in a workflow is the simplest way to guarantee correctness of operation, but this may minimize the use of available resources and maximize the time to completion.  
• Another approach is to identify all critical or dependent data objects and resources in a workflow and include “triggers and checks” that make sure all dependencies or “rights of use” are met before the object is accessed or modified.  

Data Coherency

Even with a well-designed workflow, certain best practices must be followed to avoid common issues of a stalled workflow (e.g., deadlock, livelock, starvation, failure in the absence of contention), reliable operation (e.g., the system crashes or the workflow is interrupted in a critical section), and dependency management (e.g., time between syncing of offline workflow processing devices).  

• Firstly, all workflow designs should be subject to a detailed design review by all stakeholders, and made to adhere to a documented set of best practices in workflow design.  
• Other examples include fine-grain locking of critical sections/objects of a workflow should be used to guarantee data coherency in the workflow.   The data collection devices (e.g., smart phones, tablets, laptops, etc.) should be connected to the project management system and/or synced with the main database system as often as possible.  The project management system should notify the associated project manager and field service representatives anytime an assigned and active workflow has not been synced for a pre-subscribed amount of time.  A workflow must be released from a field service representative before it is reassigned, avoiding unauthorized data updates.

There are key functional requirements in the project management system, workflow engine, field service device interface, and database system to enable concurrency of operations in a workflow and ensure correctness in the data collected/created.  Enabling concurrency in a workflow can be key to maximizing efficiencies in the delivery of field services.

A successful project management system must include or integrate with an adaptive and effective quality management system.  ISO (the International Organization for Standardization, 9000:2015, https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v1:en) defines a quality management system (QMS) as a set of well-defined policies, processes and procedures required for planning and execution in design, development, production, and services in business areas that can impact the organization’s ability to meet customer requirements.  Some people generically refer to a group of documents as a QMS.  But specifically, it refers to the entire system – the documents just describe it.  An effective QMS enables the organization to identify, measure, control, and improve the various core business processes that will ultimately lead to improved business performance.  To date there are few, if any, QMS that integrate the tracking and monitoring of physical services activities with advanced analytics to deliver real-time insights and actions in support of optimized field services for infrastructure systems.

Quality assurance (QA) and quality control (QC) are two key aspects of a quality management system. While some quality assurance and quality control activities are interrelated, they are inherently different. Typically, QA activities and responsibilities cover virtually all of the quality system in one fashion or another, while QC is a subset of the QA activities.

QA is defined as “part of QMS focused on providing confidence that quality requirements will be fulfilled” (https://asq.org/quality-resources/quality-assurance-vs-control).  The confidence provided by quality assurance is twofold—internally to management and externally to customers.  As a subset of QA, QC is focused on fulfilling quality requirements.  While quality assurance relates to how a process is performed or how a product is made, quality control is more the inspection or verification aspect of quality management.  Auditing and inspection can be another important part of the quality assurance function, defined as comparing actual conditions with requirements and/or expectations, and reporting those results to management and/or other organizations.

Like manufacturing systems, infrastructure systems and related field services have started to deploy technology enabled capabilities. These can support the effective implementation of advanced quality management functions.  

The first key technology enabler is the Internet of Things (IoT) with integrated sensors and controls, where each major component of an infrastructure system is connected to the internet, monitored and/or controlled, and data is collected.  Unfortunately, IoT deployments produce massive amounts of real-time data, which can be challenging for field service providers to effectively use without some advanced tools.

The second key technology enabler is analytic solutions. These solutions can provide more accurate and faster insights. Initially, raw data from IoT and modern infrastructure systems were not ready for analytics. Unfortunately, analysts must clean, extract, transfer and load (ETL) data, seriously constraining the QMS system’s ability to provide real-time controls and/or predictive services.  To address this constraint, automated data validation or checking technology must be integrated into the system, between the IoT components and analytics engine, to support collection of clean real-time data that can be correlated and effectively used in computer algorithms and analytics to produce accurate insights, responses, and reports.  

One approach to adding analytics to the management and servicing of infrastructure systems is to mash up or stack QMS solutions with analytic solutions.  Note, however, that this approach will produce a loosely coupled platform unable to support real-time controls or service activities. While this mashup may support some level of dashboarding and reporting on operations, it would not deliver the advanced and/or differentiated capabilities expected by today’s customers.

The ultimate goal is to integrate the analytics engine with the QMS so completely that neither the service provider nor the customer will even know they are using advanced analytic techniques and machine learning. This tight integration of QMS and analytic solutions will help users be more productive and accurate in their decision making and service delivery. This integration will also enable automation of reports, guides, and alerts.  Actionable information will appear in context to help make better quality decisions without having to jump to a different analytic user interface. Quality investigations and decisions will ultimately be streamlined to improve the quality of any field service delivery solution.