I voiced the following opinion at the last ISA-95 meeting and then last week on the ISA-95 List server. Bottom Line: The standard is getting widely used but is getting updated with no or very limited end-user input. I have made call for end users to step and get involved, but only two did. The vendors are saying the end users do not have time and that they represent their opinions in the standards. THIS IS VERY DANGEROUS AND WRONG!
Let’s debate.
End users, I need, WE need, your opinions on this NOW, since you will be the ones living with it and creating more custom hybrids of 88 and 95 that still require custom translation for compliant interfaces.
Since I come from the discrete and MTO batch worlds, I find many, many end users utilizing product and process segments for execution, not just for Level 3 to 4 exchanges and business views, but to describe Level 2 and 3 manual and automated workflows and even for master and control recipes utilizing 95. Why? Because they want their interfaces, analytics and reports to be more configured from the application data model and transaction set. They want reduced complexity. Otherwise, the B2MML+ interface is simply less custom, but still custom translation. Many of these companies find that doing just the current 95 to 88 or 88 to 95 adds too much complexity. Now we want to add another operations segment for level 3 detail distinction.
There are good arguments for and against this. So at Sun Valley meeting I argued this point to exhaustion and compromise on the first day. I believe that the big process vendors and companies drive these standards to the “exchange only” form so as not to disrupt their DCS platforms. In the discrete and MTO batch world, they are just beginning to automate their MOM workflows from paper to interoperable systems mapped to business processes, and they see the need for the expense of custom interfaces, analytics and reports as very excessive even to the 95 or OAGIS baseline. Remember, at least 80% of batch manufacturers are still using their own standard as opposed to an 88 hybrid. Why? I see large process manufacturers, SAP and large DCS vendors driving 95 into a vertical industry-specific form. It is an ISA standard after all. If this is what is wanted by actual contributors, this is great. Just understand when other industries customize it to their needed form. Non-process end users will simply use it as a starting point for custom application and interfaces, which throws interoperability out the window in the supply chain.
The proposed changes in Part 2 propose transformation of the process segment (business view) at scheduling/dispatching into an operations OR (not and) work process segment for execution of the actual order. I thought that we agreed on that middle ground of JUST the operations segment that would then identify the activity (production, quality test, maintenance, inventory) in the properties. I see the 95 group divided, since many application data models and some software products have utilized the “process segment” in level 3 for execution and in discrete in level 2 and 3 for execution.
End users from all verticals need to get involved on the list server discussion and through the submission of comments NOW; otherwise the result will be that each customer will have a custom application of 95 and 88 to describe work execution in terms of either 88 structures, a process segment or an operations segment. Currently, many end users NOT in process industries (where the vendor’s DCS data models control the existing Level 3 and Level 2 applications installed base and have for years since these industries automated in the 80s and 90s)) are applying 95 to the floor with a process segment for discrete execution or are applying an 88/95 transformation at the master or control recipe.
To reduce complexity and transformation, I have even seen a large global tobacco company reject 88 entirely and utilize a hybrid 95 execution application to create recipes and discrete routes that map seamlessly to each other. Also, I have seen a large global beverage company do the opposite, using 88 for batch and discrete execution and then use a 95 data collection data model for analytics, reporting and interface configuration. To reduce complexity further, I have also seen a large global brewer corporately apply a pure 88 scheduling and execution application across batch and discrete workflows from Level 2 to Level 4 where custom BatchML and 88 tables were built in SAP. This was true interoperability and adaptability. Very nice capability model for batch.
As far as the standard goes, there are many end users whom I have worked with or taught who want the 95 committee and Part 4 to go much further
1. Address more than just the exchanges in and out of an activity model. Address the exchanges between function within the activity models. We actually did this in the 95/SCOR Alignment Working Group.
2. Address the data models for each activity model application so that the interfaces, reports and analytics are configured rather than a customer mapping and modeling translation.
3. Address execution
4. Address configurable back applications of data collection, analysis, tracking and interfacing
5. Address the discrete application
6. Outline Level 3 business processes by production type
Yes this very hard. Exchanges are easy and only solve 25% of the interoperability issue. You still are not producing an adoptable interface.
Why are we here? All of this was done because the resource-starved 88 and 95 committees (for years) did not address discrete execution or the 95 Level 3 exchanges or data models until Part 4 for 15 years as the world moved to a pull, make-to-order global economy. Now we have a global market place that needs these standards completed to a higher state, and the end users are not getting involved. We now have a large number of variations out there which will only grow larger if we have an confusion on the operation segment for Level 3 exchanges and scheduling and then a work process segment for execution, data collection and analysis.
Other than Jean and Bianca, the European community’s is simply participating in the development of the 95 standards BUT are, by far, the largest group of end users. It is time to step up Europe and get involved. I loudly voiced my opinions and experience examples at the last 95 meeting, but I had no backup. Maybe I am just wrong. The 88 and 95 committees in the US are dominated by the process industries, so the limited resources focus on THAT Level 3 problem set ,as I would if I worked for large process company and invested time and money in the committee.
The European manufacturing base is applying these standards to make their remaining plants that have not been outsourced more adaptable and competitive in the global market. So these plants are right sizing their batch and discrete process for flexibility. The USA base is next, in my opinion. This is why Europeans are applying 88, hybrid 95 or both at the execution applications. Europe needs to get involved much sooner than at the IEC step. This is why 95 is a process standard and addresses only exchanges and not execution or even the Level 2 exchanges which, again, has led to many custom 88 and 95 custom hybrid implementations.
Having just an exchange standard is leading to custom implementations, since the applications have to still be converted into a B2MML, BatchML or future MOMML form, and the original application data model, more than likely, does not have a capability model that separately models work segments and resources independently. Most Level 3 products just model a product-related segment or route or recipe which FAILS to abstract out the resources and segments for plant capability analysis that can be applied for true adaptable manufacturing in a product independent manner. The Lean zealots loves this flaw about the current Level 3 product set on the market.
So we as a group have actually solved very little towards our original 88/95 goal of separating resources from product types for adaptability.
We need to make our meetings more virtual and inclusive even though this does do not work very well. We need more actual end-user examples other than the 3 or 4 we reuse in a knowledge center of some kind. Who wants to step up and do this? We can make our VOICE of the customer better. Actually implementation and business cases should drive the standard, not vendors and lack of resources.
