Tagged: Integration RSS Toggle Comment Threads | Keyboard Shortcuts

  • Edward Brown 3:15 pm on April 13, 2010 Permalink | Reply
    Tags: Electronic Work Instructions, , EWI, Integration, LIMS, , , PLM, , , , , Standard Operating Procedures   

    EWI – Lightening in a Document 

    First, I’d like to thank  Grant VokeyGerard Ipskamp, and Jean-Luc Delcuvellerie for their contributions in the LinkedIn Manufacturing Execution Systems Group discussions.   I find these group discussions to be a rich and thoughtful source for all things MES.

    Electronic Work Instructions, what are they?  Good question…  you may not like the answer.   The only way to answer this is to understand, at a high level, what they could be, and at the ground level, how they are implemented in different packages.   

     First, it helps to understand where they’ve come from.  Standard Operating Procedures, SOPs, have been part of the manufacturing environment since production managers could write down instructions.  Typically you’ll find these kind of instructions on the production floor on a laminated sheet (or sheets) hanging at an operation or bound in a humongous book in the quality office for every product and procedure.  They’re a big step in the right direction.  Getting your people to know what the right process is, and following that process is huge.  So…  problem solved?  Not really.   So, thinking that through… what happens when I have a change to the document?   Let’s say R&D has improved the operational procedure for a handful of products.  How does the change happen?  New documents are printed and distributed to the right locations.  When do you change over?  How do you coordinate the release of the document with when you want that new procedure put in place?  And this is really the simplest case.  Let’s consider what else might be in that SOP.  If we include setup instructions, quality inspection instructions, or production data collection instructions in the SOP, this document becomes a living document.  Each area of information may be managed differently, by different groups.   In addition, the information for each may or may not be related.  How do you coordinate this disparate data?  How do you make sure the right data is updated in the document at the right time and appears at the operator when it’s supposed to?

    Managing this kind of information in a pure text document is both difficult and ineffective.   This has driven the need for Electronic Work Instructions, EWI.   So… what could EWI be?  Since there isn’t a definition in Wikipedia, I’ll make one up.  It could be an electronic document that contains embedded data fields that can be managed and distributed either automatically or according to some scheduling criteria.   I would add that there are some ancillary functions that actually make this manageable and useful:

    • Document Versioning – An important feature, especially useful in a flexible production environment, or where rapid product changes occur.
    • Review and Approval – The ability to create/modify a document and route it for review and approval.
    • Data Integration – The ability to add or update data fields in the document based on an external data source (e.g.  Control Limits for a given product and operation).
    • Distribution Management – The ability to schedule document distribution or initiate distribution based on business rules (such as release coordination with new products).
    • Hierarchy – The ability to structure a master document with related sub-documents.  For instance a master document for Product A may contain sub sections for production, quality, safety, sanitation, etc.  Each of these sub sections may be divided into smaller divisions based on operations for instance.
    • Security – The ability to control who may read, create, or modify documents.
    • Electronic Signatures – Having the ability to record sign-off on a document is incredibly useful.  This is usually the cornerstone of becoming CFR 21 part 11 compliant, providing auditable records that can be easily retrieved and reported.

    Once we’ve created a document and know how to publish it when we need to, we also need to be able to control access to it.  Actually, we’d like to coordinate document access with production processes, so that the right document (or sub-section, or sub-section item) is made available based on production conditions.  What conditions?

    • Operations – Displaying the right document item based on the production operation
    • Product – ditto for the product, usually in combination with Operations.
    • Quality Status – Showing the right quality procedure based on sampling results and showing the procedure for further testing/evaluation.  Things like Hazard Analysis and Critical Control Points, HACCP, Corrective and Preventative Actions, CAPA, and Material Review Board, MRB fall into this category.
    • Setup or Changeover – Displaying the right document for machine/unit setup based on a product change.
    • Sanitation or CIP – Displaying the right document for sanitation or clean in place operations before or after a production run.

    All of the above require extensive coordination.  That’s why EWI has become more main stream in MES applications in the last few years.   You mean EWI creation and management in MES?  Well… Yes and no.  Yes, there are packages that have most of the required EWI capabilities in them.  What better way to determine current production state than through MES.  No argument from me.  MES applications typically have an intimate awareness of operations and the production state.  The issue is the information embedded in those documents.  Much of what should be there comes from Product Life-Cycle Management, PLM, applications, Enterprise Resource Planning, ERP, applications, or Laboratory Information Management System applications.   If you create those documents in a MES EWI function, then (if you don’t have some mechanism for automated updates) you have to manage that information in multiple systems.  You just don’t want to go there.  Better to use the MES EWI as a kind of reference engine, letting it retrieve the appropriate document from another location or system based on production conditions. 

    So if we only point to the documents we need from MES, where should the documents be created?  No simple answers here.  ERP’s typically have some capability to create and manage these documents.  PLM’s are usually a better place to keep/manage them simply because the majority of the information needed is managed there anyway.  PLM’s also usually have the ability to distribute those data elements (like limits, set-points, sample id’s, etc) to other systems.  PLM’s aren’t for everyone however.  They aren’t cheap and require a resource investment to keep them fed with current and accurate data.  However you choose to implement EWI’s (or a combination of EWI and document management) there are some important factors to consider:

    • Minimize the management of document data to as few systems as possible – keeping systems synchronized can be painful and unreliable.
    • Use the MES EWI system to refer to documents – freeing the MES EWI function from document management functions simplifies the MES configuration and keeps the data in the system of authority.
    • Develop alignment between systems – Making sure the ERP operations and the MES operations share common boundaries will ensure that the right document with the right data arrives at the right time.
    •  Data Integration – Mapping out where and how data is managed before implementing an EWI can significantly reduce data integration requirements and significantly increase data accuracy and timeliness.

    EWI can make dramatic improvements in production efficiency and quality.  How you choose to implement it really depends on your product mix, production complexity, and to a large part your IT infrastructure.

     
  • Edward Brown 2:33 pm on February 25, 2010 Permalink | Reply
    Tags: , , , , Integration, Interface, , , , , , , , System Roadmap, Touch Point Agreement,   

    MESA Part 5 – Forging a Path Forward 

    This posting is a continuation of the “MESA to Change Direction?” posting.  This series discusses how to implement MES systems using a Business Process Management approach, looking at the manufacturing processes and then determining how to implement those processes through changes in how operators perform tasks and the technologies that enable those changes.

    It’s not enough to simply hold workshops solve world hunger and sing Kumbaya.   Having a roadmap, a plan for change, and the business case to back up our claims for improvement can make it a reality.

    Ok, so we’ve held the workshops…   WHOOHOO!   Exhausting as they are, we’re now armed with some fantastic information. Our four deliverables from those workshops look something like this:

    To-Be Process

    A process map of how each manufacturing activity will be performed in the Future State.

    During the workshops, we sketched these on flip charts or whiteboards at a high level.  Afterwards, we need to create an electronic version with all the details, both in the form of a process flow map, and a textual document describing the process.  Route it through the participants and get their sign-off.   

    System Footprint

    A mapping of the capabilities defined in the above processes to existing systems and new systems that will be required to support the Future State.    This requires some analysis.  We’ll need to determine which capabilities (or pieces of capabilities) will be performed through modification of existing systems, and which will be performed through acquired systems.  We’ll need to identify those new systems.  How?  Because many of the MES application vendors (MES, LIMs, Data Historians, PLM, etc) have developed and market their products using the ISA-95 standard its usually a straight-forward process to map the future state processes with MES application capabilities.

    Interfaces

    A collection of “touch point” agreements between systems that specifies each specific interface called out in the To-Be process.   This provides the information we need to get the IT department in gear.  Probably the most important piece of this deliverable though is a Data Walk-Through.  This takes our future state process, assigns real values to the data transferred between systems so everyone can see how their processes will be expected to work.  I can’t emphasize enough how important this is.  Just seeing the real data will bring everyone down to the reality of how the new process will work.

    Business Case

    A high level business plan that contains:

    • Description of the objectives
    • A list of requirements
    • A Gap Analysis
    • A description of the change management issues
    •  A migration plan
    • Expected ROI’s by activity

    Objectives – We’ve already collected these for the workshops, we just need to include them to frame the business case.  We can also provide some high level statements, from analysis of our future state and ROI, for how our new way of doing business will meet our objectives.

    Requirements – Since we’ve conducted our workshops based on ISA-95 capabilities and functionality, we need to capture those capabilities and assign a priority value to each.  The intent here is to form the basis for selection of technologies and provide justification for changes in current business practices. 

    Gap Analysis – Working from our list of shortfalls from the workshops we can now develop a gap analysis that describes how the new process addresses those shortfalls, or describes the mitigation plan where the processes do not address or solve the shortfalls.

    Change Management – By including a change management champion in our workshop sessions, we’ve been able to collect change management issues, bring them into the discussions of future state, and begin the planning to address them.  The list of change management issues may surprise you but it’s imperative that the company is aware of and planning for the changes in how you will do business.  Change issues can range from simple tweaks to the way a department handles a transaction, to an overhaul in how documents are managed and employees are trained or certified.

    Migration Plan – No matter how you will proceed, having a roadmap for how you will get there is critical.  A high level technical roadmap that calls out the order and timeframe of implementation of the systems needed to support your future state can provide the budgeting information you need to sell your program internally.   Don’t think it’s all about the budget either, having a plan for implementing fundamental capabilities or capabilities that have far reaching impact in your organization can help you transition smoothly and more efficiently.

    Return on Investment – All the work we’ve done in the workshops to determine the costs of the shortfalls we’ve identified pays off here.  Remember that each workshop was set up for a particular set of capabilities or functions, and that we’ve collected the shortfalls, and the costs of those shortfalls for those capabilities.  In addition, we’ve identified estimates of lost opportunities during those workshops.  This defines our ROI for each of those activities.  Having this granular level of ROI allows us to do one very important thing, we can measure it.  Along with the identification of the ROI for each activity, we’re going to identify the KPI that measures how well we will accomplish the improvement we seek.

    OK, that’s great!  We’ve got our workshop deliverables.  Now what do we do with them?

    Next time – Making It Real

     
  • Edward Brown 9:17 am on February 4, 2010 Permalink | Reply
    Tags: , , Integration, , , Process Flow, , , ,   

    MESA Part 2 – Business Process and MES 

    This posting is a continuation of the “MESA to Change Direction?” article that pointed out the results of an Aberdeen Group survey suggesting MESA may want to emphasize Business Process Management approaches to MES implementation.

    It’s Not an IT Initiative

    Most MES practitioners have been through the following scenario…. The client asks you to implement an MES package and gives you a set of requirements for configuration.  The IT Team is the only source of information you have.  It’s an IT initiative.  Requests for Production, Quality, Maintenance, and Engineering participation fall on deaf ears, token attendance at meetings is the best they can do.  You know it will be a disaster.  IT will love it, production won’t use it, cost accounting could care less, quality is mad, and engineering will do everything in its power to subvert it.  It will be dead before it hits the first terminal.   Besides the change management issues here, there is an obvious gap between the top floor and the shop floor.  Production, Quality, Engineering, and Maintenance not only need to be part of the change, they need to be driving the change.  Methods for Business Process Management really can help.  Combining BPM with the ISA-95 model is even better.  The ISA-95 model (part 1 and part3) does a great job of outlining the manufacturing activities that 99% of all manufacturers do now, or should do.  They also suggest how those activities might interact with others.  This is the real power of the ISA-95 standard, it provides a basic template to help companies organize, review, and improve how they do business.

    Game Plan

    Combining the ISA-95 model and Business Process methods is really very straight forward:

    • Provide Focus – Get the company objectives and strategies from the top.
    • As-Is State – Determine how manufacturing activities are currently performed
    • Future State – Hold Consensus Workshops to determine how activities will be performed in the future
    • Roadmap – Develop high-level process flows, requirements, and how they fit into a timeline

    Providing Focus

    Effective BPM relies on a cohesive and coherent framework.  It is absolutely critical that top management provide that framework in the form of goals and objectives for manufacturing.  For example, the VP of Operations may have objectives related to product mix and manufacturing flexibility.  The VP of Quality may have objectives related to minimizing and tracking product escapes.  Those objectives provide the constraints and focus for consensus workshops used to develop new or improved manufacturing/business processes.  This seems extremely obvious, but the simple process of getting the message from the top and using it to provide focus during discussions is invaluable. 

    As-Is State

    There are three universal truths about a Company’s thinking on the way they currently do business:   1) They’re pretty sure the right people know how it works, 2) It isn’t true, and 3) They really hate putting it down on paper.

    The second item becomes clear when a company actually does put it down on paper.  Yes, Betty in procurement knows exactly how to order inventory restock from consumed inventory last month.  She doesn’t know how Bill the Production Manager counts production and consumes inventory.  Getting it down on paper lets both parties see the bigger picture.  This is key if you want both parties to understand the value of information exchanged between functions.   And you do.  Determining the impact of shortfalls and improvements requires this more holistic view.

    Using the ISA-95 activity model is a great place to start discussions on the As-Is state.  As an example, consider the following activity descriptions:

    2.0 Production Scheduling  Description
    2.1 Availability The ability to determine the availability of all resources required to produce items contained in a production order.  This may include raw materials, labor, and equipment availability and/or capacity.
    2.1.1 Provide finished goods availability to Order Processing The ability to provide the availability of finished goods inventory items.  This allows the planner to plan production for the shortfall between requested sales order quantities and existing finished goods quantities for that item.
    2.1.2 Provide available production capacity to Order Processing The ability to determine the capacity of the available equipment necessary to produce a given item.

     

    These activity descriptions provide a guide and a focus for subject matter experts , SMEs, during discussions and laying out the process flow for each activity.  What’s a process flow?  It’s a way to graphically represent what’s going on in each activity.  Here’s an example:

     

    Process flows show the high-level activities and how they exchange information with different functions and resources.  It’s a great way for SMEs from adjacent functions to understand what is happening without getting bogged down in the details.

    An important second step in putting together an As-Is state is identifying the shortfalls.  This should be an issues list with examples.  Assigning a SME to determine the costs associated with a shortfall, based on the example, is a great way to begin to identify both the cost of doing business, and the potential ROI for future change.

    Next time:  Developing the future state.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Follow

Get every new post delivered to your Inbox.

Join 34 other followers