Again last week
the discussion of operational integration raged in few project discussions with
customers, without really understanding the arguments and I needed to pull out
a log from mid last year on Operational Data Management. Data Model Alignment
will be key in a viable interoperability architecture for level 3 applications
with out “rip and replace approach” in making Manufacturing Operations
Management sustainable and effective.
Synching between systems, people look at data warehouses , they do
manual binding, but these are just not practical in a sustainable and every
changing world. There are many systems usually upwards of 20 + systems which
come from different vendors and even if they do come from the same vendor they
implemented by different cultures in the plants. The thought pattern on “just
asset naming” is different between these groups. So the concept of Master Data
Management (MDM) for Industry is a hidden one, but we believe is a key one for
the future of sustainable solutions that are federating multiple systems
together, so expect to see investments and products to trying to address this. In
this blog I want to have a discussion on why MDM what it is, and Gerhard has
done a good job, and I will expand on it.
When you are
talking to customers you see comments and projects and so many are trying to
deal with this issue without really looking at the big problem and plan. The
same issue of naming happens with Assets between the Alarming system, MES
system, Batch System, and EAM system for example. The capacity or size of a
asset(Eg Tank) is key to their operations but often changes are made to
the actual asset and then say the EAM and alarming systems are updated but the
others are not realized, and the plant starts up with half the systems updated.
Yes now you get faults and plant delays, and trouble shooting. Imagine having a
system that is aware of all the systems that are modeling an aspect of that
asset in their data models, now you can have a “master change management” over
it been changed at one location and making sure it is changed at all systems
prior to start up, even if updates are manual.
Again
Borrowing from As Gerhard Greeff – Divisional
Manager at Bytes Systems Integration put it in his paper"When last
did you revisit your MOM?"
“MDM or
Master Data Management is the tool used to relate data between different
applications.
So what is
master data and why should we care? According to Wikipedia, “Master Data
Management (MDM) comprises a set of processes and tools that consistently
defines and manages the non-transactional data entities of an organization
(which may include reference data). MDM has the objective of providing
processes for collecting, aggregating, matching, consolidating, assuring
quality, persisting and distributing such data throughout an organization to
ensure consistency and control in the ongoing maintenance and application use
of this information.”
Processes
commonly seen in MDM solutions include source identification, data collection,
data transformation, normalization, rule administration, error detection and
correction, data consolidation, data storage, data distribution, and data
governance.
Why is it
necessary to differentiate between enterprise MDM and Manufacturing MDM (mMDM)?
According to MESA, in the vast majority of cases, the engineering bill-of-materials
(BOM), the routing, or the general recipe from your ERP or formulation/PLM
systems simply lack the level of detail necessary to:
1. Run detailed routings through shared shop resources
2. Set up the processing logic your batch systems
execute
3. Scale batch sizes to match local equipment assets
4. Set up detailed machine settings
This problem is
compounded by heterogeneous legacy systems, mistrust/disbelief in controlled
MOM systems, data ownership issues, and data inconsistency. The absence of
strong, common data architecture promotes ungoverned data definition
proliferation, point-to-point integration and parochial data management
strategies. Within the manufacturing environment, all this translates into many
types of waste and added cost.
The master
data required to execute production processes is highly dependent upon
individual assets and site-specific considerations, all of which are subject to
change at a much higher frequency than typical enterprise processes like
order-entry or payables processing. As a result, manufacturing master data will
be a blend of data that is not related specifically to site level details (such
as a customer ID or high-level product specifications shared between enterprise
order-entry systems and the plant) and site-specific or “local” details such as
equipment operating characteristics (which may vary by local humidity,
temperature, and drive speed) or even local raw material characteristics.
This natural
division between enterprise master data and “local” or manufacturing master
data suggests specific architectural approaches to manufacturing master data
management (mMDM) which borrow heavily from Enterprise MDM models, but which
are tuned to the specific requirements of the manufacturing environment.
Think of a
company that has acquired various manufacturing entities over time. They have
consolidated their Enterprise systems, but at site level, things are different.
Different sites may call the same raw material different things (for instance
11% HCl, Hydrochloric acid, Pool Acid, Hydrochloric 11% etc.). Then this same
raw material may also have different names in the Batch system, the SCADA, the
LIMS, the Stores system, the Scheduling system and the MOM. This makes it
extremely difficult to report for instance on the consumption of Hydrochloric
Acid from a COO perspective, as without a mMDM for instance, the consumption
query will have to be tailored for each site and system in order to abstract
the quantities for use.
The
alternative of course is to initiate a naming standardization exercise that can
take years to complete as changes will be required on most level 2 and 3
systems. That is not even taking into account the redevelopment of
visualization and the retraining of operators. The question is, once the naming
standardization is complete, who owns the master naming convention and who
ensures that plants don’t once again diverge over time as new products and
materials are added?
The example
above is a very simple one, for a raw material, but it can also be applied to
other resources, utilities, equipment, operating parameters, recipes, WIP and
products. If a company has for instance implemented a barcode scanning
solution, the item numbers for a specific product or component may differ
between suppliers. How will the system know what product/component has been
received or issued to the plant without some translation taking place
somewhere? mMDM will thus resolve a lot of issues that manufacturing companies
are experiencing today in their strive for more flexible integration between
level 3 and level 4 systems.
Figure blow
shows the relation between mMDM, MDM, SOA and SOAm and how they are meant to
operate together.
The objective
of the proposed split in architecture is to increase application flexibility
without reducing the effectiveness and efficiency of the integration between
systems. It also abstracts the interface mechanisms out of the application into
services that can operate regardless of application changes. This will get rid
of numerous “point-to-point” interfaces and make systems more flexible in order
to adapt to changing conditions. The SOAm architecture also abstracts business
processes and their orchestration from the individual applications into an
operations business process management layer. Now, one person is able to
interact with multiple applications to track or manage a production order
without even realizing that he/she is jumping between applications.
Even with SOAm
and mMDM, integration will not be efficient and effective unless message
structures and data exchange are in a standard format. This is where ISA-95
once again plays a big part in ensuring interface effectiveness and
consistency. Without standardized data exchange structures and schemas, not
even mMDM and SAOm will enable interface re-use.
ISA-95
provides standards for information exchange as well as standardized data
structures and XML message schemas based on the Business-to-Manufacturing
Mark-up Language (B2MML) developed by WBF, including the verbs and nouns for
data exchange. Standardizing these throughout the manufacturing operations
ensures that standard services are developed to accommodate multiple
applications. “
Why not a
central directory “Yellow Pages” that manages this relationship without
replication????
No comments:
Post a Comment