Our desire to add features and functionality to applications in order to solve the ever-changing challenges facing Process Manufacturing has driven up complexity. There has been a lot of focus on application product and program management using such techniques as Lean, Agile, and SCRUM, justifiable given the failure rate of IT projects. However our thesis is that sustainability of an application over its 5-7 year deployment life deserves far greater attention; what is the advantage of having an optimal application that becomes shelf-ware after 18 months due to its user-complexity, when a sub-optimal application remains in use throughout its life? Such minimalism has been embraced so successfully at Apple (Steve Jobs and Minimalism).
IT Project Rule of Five
Some may have heard of the IT rule of 5: 5 times projected cost, 5 times projected schedule, 1/5th projected functionality! Not entirely unjustified when The Standish Group reported:
Specifically, 32 percent of IT projects were considered successful, having been completed on time, on budget and with the required features and functions. Nearly one-in-four (24 percent) IT projects were considered failures, having been cancelled before they were completed, or having been delivered but never used. The rest (44 percent) were considered challenged: they were finished late, over budget, or with fewer than the required features and functions.
Thus there is justifiable focus on the development and deployment phases of a Process Manufacturing application with some notable successes. For example we believe that adopting Lean Software Principles, using Agile development methodologies such as SCRUM, provides many advantages over the traditional waterfall approach, allowing usability problems to be detected early and avoiding excessive functionality that is not required by the end-user.
Projects are justified by the ongoing benefits to the organization. However we find that many successfully deployed applications are no longer in use a few years down the road. Ask yourself how many applications that you know have become shelf-ware, no longer used and fulfilling no useful purpose for the organization.
Given that most applications are justified using an assumption of 7-year use, an active life measured in months or a few years puts that application into the category of ‘challenged’ along with those that were late , over budget, or with fewer than the required features and functions.
Declining Application Benefits
What is happening to cause the ongoing benefits to decline? There are many reasons, some of which are as follows:
- Degradation of quality of application configuration:
- Applications are becoming increasingly complex so they depend on configuration that is an accurate reflection of the underlying process. As soon as the originally deployed configuration starts to err away from the actual changes that are occurring on the plant, the application becomes less useful and consequently less beneficial. An example might be an enterprise material balancing application whose model no longer reflects reality.
- Loss of expertise, no business processes:
- There is usually an internal application champion who sees the application through to successful deployment. This catches the eye of management so the champion is moved on to higher and better things. However without a champion succession plan, the application may lose its appeal, and usage will drop.
- Failure to adapt to changing business processes:
- Most applications are designed to reflect the business process, whether or not that is the ‘as-is’ or ‘to-be’. Unfortunately business processes are a moving target. New regulations might change the way you have to do things. Better operational procedures might demand a change in business processes.
Process Manufacturing Application Focus over the Years
Perhaps the problem of sustainability lies in the process manufacturing application focus. Once the problem was that of measurement data in silos, solved by the introduction of real-time historians. However that created the problems of data visibility, solved by the introduction of graphical user interfaces. This introduced data overload which was partially solved by the introduction of analytical tools to digest the information and produce diagnostics. Unfortunately these tools were difficult to deploy across all assets within an organization, so we have been trying to solve that problem with information models. The current problem is how to convert the diagnostics into actionable knowledge with the use of work-flow engines.
As we solve one problem, another emerges. Each layer of technology, however, increases the overall complexity making it more challenging to sustain any application.
|Process Manufacturing Application Problems and Solutions over the Years|
|Problem||Measurement data in silos||Data access and visualization||Analysis and business intelligence||Contextualized information||Consistent actioning||Sustainability|
|Real-time databases collecting measurements
|Graphical user interfaces, trending and reporting tools
|Analytical tools to digest data into information and diagnostics||Plant data models (ProdML, ISA-95, ISO15926, IEC 61970/61968, Proprietary)||ISO-9001||Outsourcing
|Consequence||Data but no user access||Data overload||Deployability of analysis to all assets||Interpretation limited to experts||Complexity, much more than RTDB, limiting sustainability||Improved ongoing application benefits|
|Response now||Composable integration
(Semantic Federation of external data)
|Composable UI (Portal)||Composable analysis (Complex Event Processing, Odata-Entity Descriptions)||Composable model
|Composable workflow||Composable platform and data(PaaS/DaaS)
Changing Focus to Sustainability
So if we want to sustain an application’s benefits we need to start focusing on those aspects of the application’s technology, development, and deployment that is designed to improve sustainability. This may lead to less than optimal applications but what would you rather have; the optimal application that yields 100$/year for 2 years, or a sub-optimal application that yields 80$/year for 7 years?
Sustainability of an application is a multifaceted problem. Below is a catalog of some of the problems, together with the proposed solutions.
|All problems lead to sustainability|
|We cannot afford experts to create a rigid 5 year plan nor will we follow it with the staff turnovers we have.||Solutions must deliver incremental value with additional solutions building upon the installed platform.||Agility||Sustainability|
|We are too small to have a large IT department.||Solutions cannot increase the size of the internal IT. Outsource IT.||Affordability|
|We cannot afford to be good custodians of our data, nor want to manage its increasing complexity.||Outsource data management to the ‘cloud’: Data management as a Service, DaaS = Google Fusion/Dydra.||Capability|
|We do not have in-house experts to continually adapt to my changing business needs and changing regulations.||We must make the solutions easily adaptable with built-in best practices (data, presentation, analysis, and work flows).||Adaptability|
|We are growing, and do not want the IT apps to impede that growth.||We must make the solutions self-configurable or configurable with the minimum of skill.||Configurability|
|We do not have the in-house skills to deploy such technology.||We must make the solutions self-deploying
with built-in best practices.
|We will be employing Gen Y/Gen Z who are used to iPhone, Twitter, Facebook, and other social applications where they can change their own experience.||“A true web2.0 app gets better the more people use it…” Tim O’Reilly.||Sociability|
|I only want to pay for what I use, and want to avoid large capital investments.||PaaS, SaaS, DaaS Cloud.||Affordability|
|I don’t want my people to have to become IT experts to use any application.||Applications should have the same intuitiveness of use as the iPad, Facebook, etc.||Simplicity|
|My business and how I run it is different than everyone else’s; this is my competitive advantage.||Composability of applications without constructing new, custom code.||Composability|
|I do not want to put all my bets on a single vendor because they cannot be an innovative as the ‘crowd’.||We should use standards and de-facto standards so that additional applications and utilities can be ‘crowd-sourced’.||Constructability|
|I want my best practices to be owned and managed by the business rather than individual experts within the company.||Analytics, diagnostics, work-flow automation, event-processing, inferencing, knowledge management.||Quality|
|Regulations demand that we demonstrate strong governance over information and decisions||Audited data and transactions, change management procedures.||Auditability|
Ensuring Solution/Application Sustainability
In the article ‘Solving or simply displacing problems: Application HAZOPS?’ the issue of problem displacement was discussed: do information technology ‘solutions’ create more problems than they solve, do information technology ‘solutions’ simply displace problems to another group? HAZOPS have been used to systematically assess safety risks in processes and operations. Why not ‘HAZOP’ the supposed information technology solutions that we propose?
Thus given the potential problem of sustainability, we propose conducting a Solution Sustainability Assessment, based on HAZOP principles as shown below. This should be included within the solution evaluation along with conventional criteria such as project and deployment costs and schedules.
|Solution Sustainability Assessment (HAZOP) – Example|
|Agility||Solution must deliver incremental value with additional solutions building upon the installed platform.||Business requires extended functionality due to change of business practice or regulation.||Solution does not offer the required extended functionality.||Add an independent solution offering the extra features and integrate together.|
|Affordability||Solution cannot increase the size of the internal IT.||Solution has increased internal IT support requirements beyond that which we can sustain.||Reduced IT budget.
Increased solution portfolio without increasing IT budget.
|IT support deteriorates.|
|Capability||Solution cannot depend on establishing our own good custodianship of our data, nor manage its increasing complexity.||Increased complexity of custodianship of configuration data.||Effective use of the solution requires increased complexity in the custodianship of the configuration data.||Trust in solution results deteriorates.|
|Adaptability||Solutions easily adaptable with built-in best practices (data, presentation, analysis, and work flows)||Business requires adapted business practices encoded in solution.||Business practices change in response to new competition and regulations.||Failure to capture benefits of improved business practices.|
|Configurability||Solutions should be self-configurable or configurable with the minimum of skill.||User fails to configure application to meet their changed needs.||User training insufficient to allow self-configuration.
Solution more complex than expected inhibiting users from making their own changes
|Users rely on in-house experts or IT to make changes, increasing costs.|
|Deployability||Solutions should be self-deploying
with built-in best practices.
|Upgrade of solution not self-deploying.||Solution is within a domain with rapidly changing regulations.||Solution upgrades delayed so that users are forced to use obsolete solution and outdated business practices.|
|Sociability||Value of solution should increase with more users (see Should Enterprise Applications be evolving to Socialized Enterprise?)
|Addition of more users||Addition of more users simply increases IT load with no improvement of business. Users not taking advantage of the intra-solution features (notifications, document sharing etc) to improve their business practices.||Solution does not improve interactions between departments as planned.|
|Affordability||Should only pay for what I use, and want to avoid large capital investments.||Cost not proportional to users or usage.||Licensed by server or site, not by users or usage.||Reluctance to sustain license as cost per user greater than anticipated.|
|Simplicity||Solution should not depend on my people becoming IT experts to use any application.||Needs a local expert for effective use.||Solution more complex or intricate than expected or solution’s configuration became overly complex.||Hidden cost of sustainment.|
|Composability||Composability of applications without constructing new, custom code.||Need to improve efficiency in use.||User needs to create new mash-up to avoid viewing separate reports and/or pages.||User’s efficiency degrades|
|Constructability||Solution should use standards and de-facto standards so that additional applications and utilities can be ‘crowd-sourced’.||Need another utility.||Need another utility.||Expensive to add a new utility.|
|Quality||Solution should have built-in process quality management: Analytics, diagnostics, work-flow automation, event-processing, inferencing, knowledge management.||Measurability of process quality.||Need to ensure that the process quality is adhering to Sarbanes-Oxley, ISO-9001, Lean and other guidelines/regulations.||Lack of confidence in the quality of the processes that are automated by the solution.|
|Auditability||Audited data and transactions, change management procedures.||Some transactions now need to be audited.||Change of business practice now requires additional transactions be audited.||Solution may need to be replaced if auditing is mandated.|