Operations Innovation & Transformation – 3 Questions

by Stan Devries, Sr. Director Solutions Architecture, Schneider Electric| Invensys

On February 4-6, 2014, I posted a series of articles by Stan covering Operations Innovation.  He explained innovation as a quadrant; joining people, assets with efficiency and consistency in execution.

 

Stan reported that he had some excellent questions arise in regards to the quadrant, and called out 3 of them:

1. Can the 4 quadrant approach be applied to a single site?
2. The changes in the targets mentioned seem to be the responsibility of planning and scheduling; how do they affect Operations?
3. How does this transformation affect the solution's architecture?

The answers follow below...


Applying the 4 Quadrants to a Single Site

Sites that have multiple operations areas which produce the same product or utility can use the “network” or “fleet” asset management approach.  Sites that have multiple operations areas which produce intermediate products can use the “value chain” asset management approach.  The operations transformation focuses on shared objectives.  The previous articles highlighted examples of efficiency and consistency; other objectives such as throughput, cost, yield, and revenue are also viable.

Operations Responsibility for Adjusting Targets

Most industrial operations have a practical separation of responsibilities between planning, scheduling and operations, and the separation is defined by time.  Operations usually has the responsibility within an operating shift (a notable exception is power generation, which can be within 15 minutes).  But operations must negotiate with planning and scheduling, and operations must adjust targets (within limits) during their time frame (usually an operating shift).  These adjustments might seem to be minor, but the total effect over a year in significant.  The previous articles highlighted an approach that applies “operations control loops” which improves the accuracy and consistency of target adjustments for planning, scheduling, operations and maintenance.

Solution architecture for operations transformation

Traditional approaches to operations management solutions tend to focus on existing and proposed applications.  These approaches have some merit because the required inputs and available outputs are fixed.  But the adoption of operations management solutions depends upon complete, trustworthy and actionable information, independent of the capability of the existing and desired applications.  The recommended approach to address this is a standard from The Open Group called TOGAF, and it is one of the most popular approaches to plan and communicate architecture needs to diverse stakeholders “in their language.” 

 

The TOGAF approach has 4 views:

·         Business “architecture” – how the business processes will be transformed, enabled and governed by the architecture

·         Data “architecture” – the data needed to enable the business processes (not the data needed to enable the applications)

·         Application architecture – the applications needed to produce the data and to interact with the users and other systems

·         Technology architecture – technology needed to provide sufficient trustworthiness and cost of ownership

This approach addresses the gaps in application data in the following manner:

·         The desired operations transformation and business process automation is considered first, independent of the applications.  An example is using “expected useful life” of a type of equipment to adjust operating targets slightly to achieve the current schedule and the longer term planned equipment overhaul.

·         The data required for the business process automation is considered next, which in the above example includes a recurring estimate of the “expected useful life,”and a performance measure with workflow for the equipment, and some benchmarking across all similar equipment.

·         The applications, both existing and desired, are then assessed against the required data.  Typically, applications are available to calculate equipment efficiency or capacity at the moment, but these applications do not directly calculate “expected useful life” and do not provide benchmarking.  Therefore the applications architecture activity identifies calculation requirements, which could be implemented in operations intelligence or what is termed EMI or Enterprise Manufacturing Intelligence, to produce the required data.

·         The technology architecture can then produce the required integration, which includes the integration between the main applications (existing and desired), the additional applications, and the infrastructure required for mobility, high availability, virtualization, Cloud etc.

This approach is iterative and is “agile,” so that experts on the business processes, the applications, the required data and the infrastructure can dynamically and reliably converge on a successful architecture.