Falling into the Gap.

Author – Tim Smith

When a company is considering how to engage in Industry 4.0 and IIoT to facilitate manufacturing they are faced with several aspects to such an endeavor. 

  1. Credible source information by which to select a suitable technology or direction. 
  2. Connectivity approaches which can be implemented and maintained. 
  3. Objective charter of business needs against which a selection can be made. 

“Off-the shelf” software packages carry with them architecture dispositions which most end-users have little or no control over. The database type and deployment, the means of presentation, web or fat-client, deployment options, on-premise, cloud, distributed, scalable, security just to name a few are the considerations which end-users must either accept as fixed and unchangeable or flexible and configurable. The more structured a system is designed, the less flexible in the long term it will be. Every software system has areas in their feature-set and functionality which do not necessarily meet all the expectations of the end-users, hence a Gap. 

The “Gap refers to the space between “where we are” (the present state) and “where we want to be” (the target state).  Expectations should never reflect only one group within an organization but rather a consensus of all stakeholders who will be using the system. Let me repeat this, “using the system”.  

The more distanced from the usability of the system a selection process is, the bigger the Gap will be once the software is initiated. If the only group responsible for selecting a system will not be using it day-to-day then the potential for missing the ability of the software to evolve in the direction beyond the fixed objectives is a likely outcome. I have seen selection processes completely defined by the suitability of the product to meet IT specifications and basic usability features, completely miss the core functionality necessary for successful, scalable, prolonged application. In fact, falling into the Gap is not a possibility its an inevitability. The choice is how to make the selection in such a way to mitigate the size of the Gap. 

What do users expect? 

There are three general features which all users expect, 

  1. The product must be easy to learn. 
  2. The product must solve the user’s needs. 
  3. The product “help” must be both easily accessible and effective in resolving the user’s problem quickly.  

The next set of expectations require homework because it does not just reflect a user’s expectations of what a software package can do but it must also consider the behavior of the users. 

If the users are basically mobile, then the software must ensure usability for a mobile work force. If users will demand information but do not sit in front of a computer, then the system must be able to deliver concise expected information by methods not dependent upon computers. If a user is looking for a consistent fixed information set, then the results must be clear and structured. If a user wants to interact with the results, then the software must support the level of interaction expected. 

The software must be able to grow beyond the existing objectives without massive development costs. Many of todays “Off-the shelf” software packages are designed to provide a set of visuals with limited configuration. This approach easily meets the first three macro expectations but at the expense of flexibility and scalability. Then there are the massively flexible systems such as experienced in ERP and other business systems which require countless hours to ultimately configure and present a feature-set acceptable to all stakeholders but usually at a cost multiple times of the software itself. 

Gaps in expectation can occur through features, functions, procedures, and personnel.  

The response from developers to support scalability is to provide a system designed as modular where the basic configuration meets a reasonable set of needs and then modules can be added to support specific users’ unique needs. However, this design misses the critical objective of flexibility in presentation of information. “Off-the shelf” software by its very nature is simple and therefore restrictive. A user has a limited number of views and there is not option beyond that limitation. On the flip side you can have an open-ended toolset which means any conceivable visual can be created at a cost. The challenge is to find a package that straddles both worlds; one with a clear set of standard views and also the ability to modify and expand any of the standard views and provide the ability for users to configure whole new views without costly professional services. Within manufacturing, objectives can include throughput, delivery, utilization, performance, quality, OEE, takt, to name a few, but the system must be able to accommodate new metrics as the need necessitates.  

A system must be focused on both real-time eventing with metrics and with historical analysis and trending. Missing this aspect will undoubtably lead to Gaps in the expectation of users and the software. If real-time eventing alerts users to a state condition, the ability to assess that condition historically is critical. The ability to look for patterns in historical data is paramount and then the ability to create triggers to alert users to emerging conditions based on the historical trends will produce Gaps if not properly implemented. 

A failure point of such technology projects is directly related to the lack of stakeholder involvement in the selection process. The worse thing a company can do is to let a single individual or individuals drive the selection process, especially if they will not be using the software.  An isolated-selection approach will alienate the users who are seeking a solution. 

The second failure point stems from not assigning a champion to the project. If there is no champion, there is no outcome.  Do not fool yourself thinking the everyone will be able to drive the project. No one will drive the project unless that task becomes an integral part of their workday. 

The third failure point is to throw open a POC with all features turned on and no real objectives identified by which to assess the expected deliverables. If each group of stakeholders does not have a plan of action by which to assess the software the project will fail.  

Another critical area overlooked is the adoption plan. When the system has been tested and all objectives are met, what is the plan to roll-out the software for adoption as part of the normal day-to-day operations. I have seen where whole groups are left in the dark and ultimately the project fails. If the stakeholders lose motivation, adoption fails. 

The ability to minimize Gaps between user expectations and the software should consider these guidelines: 

  1. Select a champion, select a representative stakeholder group, develop an objectives list 
  2. Use the list to evaluate the vendor products and whether their features meet the user objectives and how scalable and flexible is the package as it relates to ERP connectivity, extensibility of metrics, features, etc. 
  3. How productized is the solution both in installation of hardware, where applicable, connectivity to machine assets, deployment of software and configuration, training, and adoption? 
  4. How secure is the product? 

If you follow this simple guideline it will minimize the Gaps which will inevitably appear between your expectations and the package you select, leading to successful technology adoption and overall satisfaction with the project and the choices made along the way