Method, system and apparatus for automatic quality control using a plurality of computers

A system and method for automatic quality control is provided. A database is maintained storing quality control rules for producing a product, the quality control rules determined via a first computing device associated with a first entity controlling production of the product, the database maintained by a second computing device associated with a second entity for maintaining quality control of the product, the product produced by a plurality of production lines respectively associated with third entities. Quality control data is received at the second computing device from data collection devices at the plurality of production lines, each of the data collection devices enabled to collect the quality control data for the product. At the second computing device, the quality control data is compared with the quality control rules; at least one quality control event is triggered when the quality control data fails at least one of the quality control rules.

FIELD

The specification relates generally to quality control, and specifically to a method, system and apparatus for automatic quality control using a plurality of computers.

BACKGROUND

Quality control in a contract manufacturing environment is demanding as a given manufacturer can manufacture a wide variety of finished goods in short period of time, reconfiguring a production line, often daily, to handle a given production run. When a brand owner contracts production of a product to more than one contract manufacturer, maintaining quality control across the different production environments can be challenge.

SUMMARY

A first aspect of the specification provides a method for automatic quality control using a plurality of computers, comprising: maintaining a database storing quality control rules for producing a product, the quality control rules determined via a first computing device associated with a first entity controlling production of the product, the database maintained by a second computing device associated with a second entity for maintaining quality control of the product, the product produced by a plurality of production lines respectively associated with third entities; receiving quality control data at the second computing device from data collection devices at each of the plurality of production lines, each of the data collection devices enabled to collect the quality control data for the product; and at the second computing device, comparing the quality control data with the quality control rules and triggering at least one quality control event when the quality control data fails at least one of the quality control rules.

At least one of the quality control rules can be normalized for a respective production line of the plurality of production lines by adjusting at least one of the quality control rules according to local data indicative of local conditions at the respective production line. The local data can comprise at least one of: a local production rate for producing the product at the respective production line; at least one setting at equipment for producing the product at the respective production line; and at least one condition particular to the respective production line.

The method can further comprise adjusting at least one of the quality control rules for a respective production line based on local data at the respective production line. At least one of the quality control rules can comprise at least one threshold value and the adjusting at least one of the quality control rules can comprise adjusting the threshold.

The method can further comprise: collecting local data indicative of local conditions at each of the plurality of production lines; and adjusting the quality control rules for respective ones of the plurality of production lines based on the local data.

A first portion of the quality control rules can originate at computing devices associated with respective ones of the third entities, the first portion comprising local quality control rules for respective production lines.

At least a portion of the data collection devices can each comprise a mobile communication device for inputting the quality control data at electronic forms stored at the mobile communication device.

At least a portion of the data collection devices can each comprise an electronic data collection device for automatic collection of the quality control data. The electronic data collection device can comprise at least one: a camera; a colorimeter, an image recognition algorithm; a character recognition algorithm; a colour detecting algorithm; an RFID (radio frequency identification) device; an RFID sensor; a barcode reader; a weigh scale; a temperature sensor; a moisture sensor; a metal detector; a vibration sensor; a pressure sensor; a gas sensor; a chemical sensor; a biological element sensor; a laser beam based reading device; a laser beam based counting device; an optical reader device; an electrical measurement device; and a counting device.

The quality control rules can comprise thresholds such that a given quality control rule is failed when the quality control data does not meet a respective threshold and the given quality control rule is passed when the quality control data meets the respective threshold.

At least one quality control event can be triggered at a first one of the third entities based on given quality control data from a second one of the third entities failing the at least of the quality control rules.

At least one quality control event can comprise at least one of: notifying the first entity of a failure of the quality control rules; notifying a respective one of the third entities associated with the failure; a recall order; a change in the quality control rules associated with at least one of the third entities; updating data collection parameters at the data collection devices; an order to quarantine inventory that does not meet the quality control rules; marking down a quality score of the respective one of the third entities associated with failure; a quality event associated with at least one of a supplier, a contract manufacturer and a contract packager; issuing a remedial action order to correct for the failure; an order to modify defective inventory to bring the defective inventory back into specification; an order to at least one of replace and supplement a defective component with another component; notifying an original maker of the defective component; notifying at least one fourth entity of the failure; an order to destroy the defective inventory; and an order to at least one of return and transport the defective inventory to another entity.

The method can further comprise triggering at least one further quality control event when the quality control data passes at least one of the quality control rules.

Another aspect of the specification provides a system for automatic quality, comprising: a first computing device associated with a first entity controlling production of a product, the first computing device enabled to determine quality control rules for producing the product; a second computing device associated with a second entity for maintaining quality control of the product, the second computing device enabled to maintain a database storing the quality control rules and receiving quality control data for comparison with the quality control rules to trigger at least one quality control event when the quality control data fails at least one of the quality control rules; and data collection devices at each of a plurality of production lines respectively associated with third entities, each of the data collection devices enabled to collect the quality control data for the product and transmit the quality control data to the second computing device.

At least one of the quality control rules can be normalized for a respective production line of the plurality of production lines by adjusting at least one of the quality control rules according to local data indicative of local conditions at the respective production line. The local data can comprise at least one of: a local production rate for producing the product at the respective production line; at least one setting at equipment for producing the product at the respective production line; and at least one condition particular to the respective production line.

The second computing device can be further enabled to adjust at least one of the quality control rules for a respective production line based on local data at the respective production line. At least one of the quality control rules can comprise at least one threshold value and the adjusting at least one of the quality control rules can comprise adjusting the threshold.

At least a portion of the data collection devices can be further enabled to collect local data indicative of local conditions at each of the plurality of production lines; and the second computing device can be further enabled to adjust the quality control rules for respective ones of the plurality of production lines based on the local data.

A first portion of the quality control rules can originate at computing devices associated with respective ones of the third entities, the first portion comprising local quality control rules for respective production lines.

At least a portion of the data collection devices can each comprise a mobile communication device for inputting the quality control data at electronic forms stored at the mobile communication device.

At least a portion of the data collection devices can each comprise an electronic data collection device for automatic collection of the quality control data. The electronic data collection device can comprise at least one: a camera; a colorimeter, an image recognition algorithm; a character recognition algorithm; a colour detecting algorithm; an RFID (radio frequency identification) device; an RFID sensor; a barcode reader; a weigh scale; a temperature sensor; a moisture sensor; a metal detector; a vibration sensor; a pressure sensor; a gas sensor; a chemical sensor; a biological element sensor; a laser beam based reading device; a laser beam based counting device; an optical reader device; an electrical measurement device; and a counting device.

The quality control rules can comprise thresholds such that a given quality control rule is failed when the quality control data does not meet a respective threshold and the given quality control rule is passed when the quality control data meets the respective threshold.

At least one quality control event can be triggered at a first one of the third entities based on given quality control data from a second one of the third entities failing the at least of the quality control rules.

The at least one quality control event can comprise at least one of: notifying the first entity of a failure of the quality control rules; notifying a respective one of the third entities associated with the failure; a recall order; a change in the quality control rules associated with at least one of the third entities; updating data collection parameters at the data collection devices; an order to quarantine inventory that does not meet the quality control rules; marking down a quality score of the respective one of the third entities associated with failure; a quality event associated with at least one of a supplier, a contract manufacturer and a contract packager; issuing a remedial action order to correct for the failure; an order to modify defective inventory to bring the defective inventory back into specification; an order to at least one of replace and supplement a defective component with another component; notifying an original maker of the defective component; notifying at least one fourth entity of the failure; an order to destroy the defective inventory; and an order to at least one of return and transport the defective inventory to another entity.

The second computing device can be further enabled to trigger at least one further quality control event when the quality control data passes at least one of the quality control rules.

A further aspect of the specification provides a computing device for automatic quality control, comprising: a processing unit and a communication interface, the processor enabled to: maintain a database storing quality control rules for producing a product, the quality control rules received from a remote computing device via the communication interface, the remote computing device associated with a first entity controlling production of the product, the product produced by a plurality of production lines respectively associated with second entities; receiving quality control data from data collection devices at each of the plurality of production lines, via the communication interface, the data collection device enabled to collect the quality control data for the product; and compare the quality control data with the quality control rules and trigger at least one quality control event when the quality control data fails at least one of the quality control rules.

DETAILED DESCRIPTION OF THE IMPLEMENTATIONS

“Light manufacturing” activity performed by contract packagers and manufacturers differs from traditional manufacturers because:

a. the finished good varies widely in form factor and composition of subcomponents;

b. these variations occur on a regular basis, meaning some production lines only exist for a few hours; and

c. the manufacturer did not design, and does not actually own or even make the components being used to assemble the finished product.

Because of this, the contract packaging and manufacturing activity is characterized as:

highly manual with minimal automation because of the rapid change and high variability of the products;

requiring frequent non-productive time for production line setup and tear down activities;

having to comply with many different quality standards beyond their control that are applied by the various owners and designers of the products they are manufacturing, and that differ depending on the product type (eg. pharmaceutical vs. food vs. electronics); and

several different companies perform the same manufacturing activity even for the same finished good, and often share the same stock of raw materials or subcomponents

Thus cost of quality control/conformance becomes higher, while the cost of failure of control remain unchanged, or possibly even greater with increasingly stringent regulations from governmental bodies like the FDA due to on-going product recall issues (food contamination, painted toys containing toxic substances, etc.).

The cost of failure of control can include but are not limited to internal failure costs and external failure costs. Internal failure costs can include but are not limited to:

1. scrap and therefore rework;

4. labor costs of performing the rework; and

5. overhead costs for extra time and administration.

External failure costs can include but are not limited to:

1. recall issues (eg. metal filings found in food product);

2. decreased sales from customer complaints (eg. products with improper taste/freshness);

3. service and support costs; and

These issues are addressed in system100, depicted inFIG. 1, system100for automatic quality control using a plurality of computers, according to non-limiting implementations. In present implementations, system100comprises a first entity101, a second entity102and third entities103a,103b(collectively third entities103, and generically a third entity; this nomenclature is used elsewhere herein). First entity101is associated with a product and desires to control production of the product. Furthermore, first entity101desires to outsource production of the product to third entities103, each of which can produce the product by way of respective production lines105. Hence, in some implementations, first entity101can comprise a brand owner and each of third entities103can comprise a contract manufacturer operating respective production lines105to produce the product for the brand owner. First entity101furthermore outsources automatic quality control of the product to second entity102, as will be presently described.

System50further comprises at least one computing device111associated with first entity101and at least one computing device112associated with second entity102. System further comprises at least one data collection device113a,113a-1at entity103aand at least one data collection device113bat entity103beach of data collection devices113enabled to collect data from respective production lines105. Computing devices111,112and data collection devices113will also be referred to herein as, respectively, device111, device112and device113.

Devices111,112are in communication via a communication network115(also referred to herein as network115) via links116a,116b. Further, data collection devices113are in communication with device112via network115, or any other suitable network, via links116c,116d. Data can be exchanged between devices111,112, and between device112and devices113as desired, using any suitable combination of links116and network115.

It is appreciated that the nature of network115and links116is not particularly limited and are, in general, based on any combination of architectures that will support interactions between devices111,112, and between device112and devices113. In a present implementations network115can include the Internet and/or any suitable combination of wired and wireless networks. Each of links116can comprise any suitable combination of wired or wireless links as desired.

In some implementations, device111is further in communication with a database121for storing quality control rules122and/or quality control rule sets123. Device112is in further communication with a database132for storing copies of quality control rules122and/or quality control rules sets123, which can be received from device111in a provisioning process described below with reference toFIG. 6. As will be described below, in cloud computing environment and/or an SaaS (software as a service) environment, rules122and rule sets123are stored at database132and accessed by device111via network115,

Device111is now described with reference toFIG. 3, which depicts a schematic block diagram of the electronic components of device111. It should be emphasized that the structure inFIG. 2is an example. Device111includes a processing unit220interconnected with at least one memory device222, a communication interface224, a display device226, and at least one input device228.

Processing unit220comprises any suitable processor, or combination of processors, including but not limited to a microprocessor, a central processing unit (CPU) and the like. Other suitable processing units are within the scope of present implementations. Processing unit220will also be referred to hereafter as processor220. Furthermore, processor220can be configured to execute different programming instructions that can be responsive to the input received via input device226. To fulfill its programming functions, processor220is also configured to communicate with memory device222. Programming instructions that implement the functional teachings of device111as described herein are typically maintained, persistently, memory device222and used by processor220which makes appropriate utilization of volatile storage in memory device222during the execution of such programming instructions, such as when processing browser application140and/or modules250described below.

Memory device222, which will also be referred to hereafter as memory222can comprise any suitable memory device, including but not limited to any suitable one of, or combination of, volatile memory, non-volatile memory, random access memory (RAM), read-only memory (ROM), hard drive, optical drive, flash memory, magnetic computer storage devices (e.g. hard disks, floppy disks, and magnetic tape), optical discs, and the like. Other suitable memory devices are within the scope of present implementations. In particular, memory222is enabled to store any suitable combination of applications and data for processing by processor220, such as rule specification interface module250a, a dashboard module250b, a notification rules definition module250c, all described below, or the like. It is appreciated that although browser application240and modules250are depicted inFIG. 2as elements separate from processor220and memory222, modules250can be implemented by storing modules250at memory222and processing modules250at processor220.

Communication interface224, also referred to hereafter as interface224, comprises any suitable communication interface, or combination of communication interfaces. In particular communication interface224is enabled to communicate with network115via link116a, network115being wired and/or wireless as desired. Accordingly, communication interface224is enabled to communicate according to any suitable protocol which is compatible with the network, including but not limited to wired protocols, USB (universal serial bus) protocols, serial cable protocols, wireless protocols, cell-phone protocols, wireless data protocols, Bluetooth protocols, NFC (near field communication) protocols and/or a combination, or the like. In some implementations, interface224can be enabled to communicate with remote computing devices (e.g. device112, servers, other computing devices, mobile electronic devices, etc.), via any suitable communication network according to any suitable protocol, including but not limited to packet based protocols, Internet protocols, analog protocols, PSTN (public switched telephone network) protocols, WiFi protocols, WiMax protocols and the like, and/or a combination. Other suitable communication interfaces and/or protocols are within the scope of present implementations.

Display device226, also referred to hereafter as display226, comprises any suitable one of or combination of CRT (cathode ray tube) and/or flat panel displays (e.g. LCD (liquid crystal display), plasma, OLED (organic light emitting diode), capacitive or resistive touchscreens, and the like).

Input device228is generally enabled to receive input data, and can comprise any suitable combination of input devices, including but not limited to a keyboard, a keypad, a pointing device, a mouse, a track wheel, a trackball, a touchpad, a touch screen and the like. Other suitable input devices are within the scope of present implementations.

Device111is enabled to maintain or execute at least a web browser application240. In some implementations, device111further comprises modules250, however in a cloud computing environment, or the like, modules250are accessed at device112, as will be described below. Accordingly, device111can be based on any computing environment that provides web browsing functionality and/or processing of modules250. For example, such a computing environment can be based on an Intel™ or AMD™ or other microprocessor, with accompanying volatile storage (e.g. random access memory) and non-volatile storage (e.g. Flash, Hard disc drive), read only memory (ROM), network interface card(s), video cards that connect to one or more displays, a keyboard, a mouse (or other pointing device). Any operating system may be used, including, for example, an operating system offered by Microsoft™, or a Linux™ operating system, or an operating system offered by Apple Computer.

As referred to above, modules250can be stored at device111, however in a cloud computing environment, modules250are accessible via browser240. For example, in these implementations, modules250can be stored remotely, for example at device112and/or at an associated device, and accessed via browser240such that the functionality of modules250is provided at device111via browser240.

In some implementations, device111is further appreciated to have access to database121, which can be local or remote from device111as desired. For example, database121can be stored at memory222. Alternatively, in a cloud computing environment, database121can be stored remotely and accessed via network115, for example in database132accessible to device112. In implementations where database121is stored remotely and modules250are accessed via browser240, it is appreciated that device111need not be specially configured with modules250and database121; rather the functionality of modules240and data stored at database121can be provided at device111via browser240.

Device112is now described with reference toFIG. 3, which depicts a schematic block diagram of the electronic components of device112. It should be emphasized that the structure inFIG. 3is an example. Device112includes a processing unit320interconnected with at least one memory device322, a communication interface324, a display device326, and at least one input device328. Processing unit320(also referred to processor320), memory device322(also referred to processor322), communication interface324(also referred to as interface324), display device326(also referred to as display326), input device328can each be respectively similar to processor220, memory222, interface224, display226and input device228, described above. Further, device112can be enabled to provide web based, cloud computing based services to device111and/or devices113, for example by providing remote access to modules250which can be stored at device112, as well as remote access to data in database132. In these implementations, device112can comprise at least one server and/or server application.

In particular, when device112comprises at least one server, device112can be based on any well-known server environment including a module that houses one or more central processing units, volatile memory (e.g. random access memory), persistent memory (e.g. hard disk devices) and network interfaces to allow device112to communicate over network115. For example, device115can be a ProLiant® Server from Hewlett-Packard Company, 3000 Hanover Street Palo Alto, Calif. 94304-1185 USA having a plurality of central processing units and having several gigabytes of random access memory. However, it is to be emphasized that this particular server is merely a non-limiting example, and a vast array of other types of computing environments for device112is contemplated. Furthermore, it is contemplated that device112may be implemented as a plurality of interconnected servers, in a so-called server farm, which are mirrored or otherwise configured for load balancing or failover or high availability or any or all of those.

Rule specification interface250ais enabled for building rules122and/or rule sets123. For example, rule specification interface250acan be accessed from device111via browser240to specify and/or build rules such as those found in Table 1, described below. Hence, rule specification interface250acan comprise a graphic user interface (GUI) for specifying and/or building quality control rule sets.

Dashboard module250bis enabled to provide notifications in browser240, For example, when notifications are to be provided to entity101, dashboard module250bprovides indications of the notifications, such as indications of quality control failures, as described below.

Notification rules definition platform250cis enabled for building notification rules, for example rules specifying when and/or who is to be notified in the event of a quality control failure.

In any event, device112further comprises a quality control rule definition language module350a, an interpretation language module350band an alerting engine module350c.

Quality control rule definition language module350acomprises a business logic layer which formats rules122and/or rule sets123specified in the rule specification interface250aGUI, and stores them in a suitable condition-action type format which can be processed by interpretation engine350b. For example, rules122can have a format of <subject> <condition> <action>, a subject specifying an item, a condition specifying a condition of the item, and an action specifying an action to take when the subject meets the condition.

Interpretation engine350bcomprises a module which processes rules122and/or rule sets123. For example, when a rule is received which is defined as <subject> <condition> <action> from sets of subjects, conditions and actions that are understood by the interpretation engine350b(e.g. as compared against lists stored in database132), then the action can be performed. Furthermore, it is appreciated that in some implementations, interpretation engine350bcan be enabled to format rules so that they are processable by devices113, or any other suitable devices. In addition, interpretation engine350bcan interpret given rules for given devices113. For example, when a device113comprises a camera and/or a colorimeter, a rule specifying a check performed by the camera/colorimeter (e.g. Rule 3 of Table 1, below) is formatted by interpretation engine350bso that the rule can be processed by the camera/colorimeter.

Furthermore, it is appreciated that quality control rule definition language module350aand/or interpretation engine35bcan be used to manage acceptable tolerances of quality control measurements, frequencies for checking or the like.

Altering rule engine350cis enabled to compare quality control data414(described below, and which can be stored in database132) collected at production lines105and compared to rules122for a given production line105, and then notify suitable entities and/or computing devices associated with suitable entities of quality control failures.

In some implementations, suitable combinations of modules350can comprise an inference engine.

It is further appreciated that modules250and modules350can be used to build electronic forms415and/or quality control instructions417comprising programmable instructions on collecting quality control data, for example, a frequency for checking quality control data and the like. In a cloud computing environment, forms415and instructions417are stored in database132for access by devices113, as will now be described. Furthermore, forms415can comprise web pages for viewing at a browser at a device113.

Data collection devices113can comprise any suitable data collection devices enabled to collect quality control data from a respective production line105. As depicted inFIG. 4, in particular non-limiting implementations, at least one data collection device113can comprise a mobile communication device413for inputting quality control data414at electronic forms415, which can either be stored at mobile communication device413or, in a cloud computing environment accessed by mobile communication device413at device112via a browser440, similar to the interaction between browser240and device112. The frequency and/or order of input of data414can be controlled via instructions417. For example, suitable forms415can be pushed to device413at a suitable time and/or frequency and/or in a suitable order by device112and/or device413can be programmed to retrieve suitable forms415at a suitable time and/or frequency and/or in a suitable order

Mobile communication devices413comprise a processing unit420interconnected with at least one memory device422, a communication interface424, a display device426and at least one input device428, and each can be respectively similar to processor220, memory222, interface224, display226and input device228described above. However, it is appreciated that mobile communication device413comprise a portable electronic device, such as a PDA, tablet device, or any other suitable portable communication device, which is enabled to collect quality control data414via forms415and/or instructions417and transmit quality control data414to computing device112for analysis, as will be describe below. Further, it is appreciated that mobile communication devices413are enable to communicate wirelessly with computing device112, and hence interface424comprises any suitable combination of wireless interfaces and in these implementations links116c, dinclude a wireless link between mobile communication device413and network115.

In some implementations, mobile communication device413can further comprise a clock device430such that times for collecting quality control data414can be determined according to instructions417and an appropriate portion of a form415provided at a suitable time.

However, in other implementations, at least one data collection device113can include, but are not limited to: a camera; a colorimeter, an image recognition algorithm; a character recognition algorithm (e.g. for detecting text and/or numbers); a colour detecting algorithm; an RFID (radio frequency identification) device; an RFID sensor; a barcode reader; a weigh scale; a temperature sensor; a moisture sensor; a metal detector; a vibration sensor; a pressure sensor; a gas sensor; a chemical sensor; a biological element sensor (e.g. sensors for sensors detecting presence of gases, chemicals, and/or biological elements); a laser beam based reading device (e.g. including but not limited to a laser based device for scanning/reading optical information such as a barcode and the like); a laser beam based counting device (e.g. including but not limited to a device including a laser beam that can be interrupted to count items); an optical reader device; an electrical measurement device (including but not limited to devices for measuring electric signals from a machine to determine, for example, a count of items via a voltage change and the like); and a counting device. In these implementations data collection device collects quality control data414from a respective production line105, and either automatically or via a manual trigger transmits quality control data to device112for analysis. In some of these implementations, data collection device113can include a wireless interface for wireless transmission of data414, while in other implementations, device113can include a wired interface for wired transmission of data414. In yet further implementations, more than one data collection device113can be collecting quality control data414from a respective production line105, with one device113acquiring data414(e.g. a camera, or the like, as described above) and another device113(such as mobile communication device413) for transmitting data414to device112.

It is yet further appreciated that each entity103can be associated with more than one device113. For example, entity103acomprises a data collection devices113a,113a-1, while entity103bcomprises data collection device113b. For example, devices113a,113bcan each comprise a mobile communication device413, while device113a-1can comprise a camera device. Hence, entity103ais enabled to collect quality control data via both devices113a,113a-1, while entity103bis enabled to collect quality control data via device113b.

Forms415and quality control instructions417can be configured via computing device111and/or computing device112. For example, rule specification interface250acan be used to create forms415and instructions417, as well as quality control rules122and/or quality control rule set123. For example, rule specification interface250acan be used to create quality control rule sets123, as will be presently described with reference to a non-limiting example for producing a product500depicted inFIG. 5.

To produce product500, an electronics device501is packaged with a cable503and batteries505in a plastic blister pack507with special promotional graphics509. It is appreciated that product500is a branded product associated with first entity101and that first entity101has contracted entities103to produce product500using respective production lines105. Further, it is appreciated that each of electronics device501, cable503, batteries505and plastic blister pack507is provided to entities103as inventory and that entities103will package electronics device501, cable503, and batteries505into plastic blister pack507as the finished product500. It is appreciated that product500is merely an example of a branded product and that any product producible at respective production lines105are within the scope of present implementations. It is further appreciated that inventory used to produce a given product come from any suitable source, for example a supplier and/or a plurality of suppliers. Furthermore, as will be described below, present implementations can be used to control quality of parts from suppliers and/or assign quality control ratings to suppliers. It is yet further appreciated that while the present example pertains to packaging a product, in other implementations, entities103can be manufacturing a product, packaging a product, assembling various products into a kit, or a combination thereof.

It is further appreciated that first entity101desires that quality control occur for product500. Hence, using rules specification interface250a, quality control rule sets123are defined for producing product500. For example, table 1 provides a non-limiting example of a quality control rule set123for producing product500:

While table 1 is arranged in rows and columns, it is appreciated that table 1 can be stored in any suitable format. Further, it is appreciated that table 1 is merely an example of quality control data set123which relates specifically to production of product500. Each row of table 1, after the header row, is indicative of a quality control rule. It is further appreciated that column “Rule #” is optional and is provided merely for reference. Indeed, any suitable reference number can be used to number a given quality control rule.

Further, each rule in data set123comprises an “Instruction” which comprises an instruction which can be provided as text in forms415and provided at mobile communication device413.

Alternatively, “Instruction” can comprise an instruction which can be performed by a given device113. For example, in Rule 1, “Check that colour of logo is between threshold 1 and threshold 2” as well as the associated thresholds, can be provided in a suitable format to a camera device at a given production line105such that the camera device is instructed to check the colour of a logo in special promotional graphics509.

Each of “Threshold 1” and “Threshold 2” are indicative of optional thresholds which can be met for each given rule. For example, for Rule 1, the colour of the logo in special promotional graphics509is to be between a range of 450 nm (Threshold 1) and 455 nm (Threshold 2). Inside of this range, the colour of the logo in graphics509will pass Rule 1 and outside of this range, the colour of the logo in graphics509will fail Rule 1.

It is appreciated that not all quality control rules are associated with two thresholds. For example, Rule 5 to “Count items in sample blister pack” has a single threshold “4”; if the number of items in a sample blister pack is 4, then product500will pass Rule 5, and otherwise product500will fail Rule 5. A given threshold not being applicable to a respective rule is indicated by “N/A” in Table 1, however such an indication is generally appreciated to be non-limiting.

It is further appreciated that in some implementations, no thresholds are associated with a given rule, for example see Table 2 below.

Another non-limiting example of a quality control rule is to record information related to quality, including but not limited to an expiry date or serial code (e.g. as in Rule 4 of Table 1). Recording such data could also relate back to traceability of given inventory and/or given lots of inventory. In some of these implementations, a quality control rule is not associated with a given threshold as data is being entered into a field of a suitable form415. For example, such a rule could specify that a serial code be entered at a given time and/or a given frequency. Such a rule could, specify, however that an empty field NOT be returned and/or that an empty field results in a quality control failure. In some of these implementations, when an empty field is returned in data414, warnings can be issued to a device113which originates the data414, indicating that the information should be entered. In a cloud computing environment, this can occur via a push of a form back to device113.

However, a rule to enter a given serial code, or the like, could include a check of the oldest expiry date of all products in a variety pack.

Yet a further non-limiting example of a quality control rule is to check that recorded information related to quality conforms to a given format, for example a format for a given family of serial codes, lot codes or the like. When the format does not conform to a given format, warnings can be issued to a device113which originates the recorded information, indicating that the information should be re-entered.

In yet further implementations, interpretation engine350bcan be enabled to determine thresholds “on the fly” depending precedents and/or more important rules, e.g. when rules are further provided with a hierarchy, and/or more programming instructions. A non-limiting example of an advanced rule could comprise “The colorimeter should check the color to be between 48 nm and 50 nm, but if the average reading is 47 nm, then shift the range to be between 46 nm and 49 nm.”. System100can be enabled to perform such an active feedback loop to determine that the difference is small enough that the additional cost of rejecting these defects might not be desirable from an overall business perspective, for example for economic reasons, based on the originally defined “unnecessarily stringent” tolerance.

Furthermore, interpretation engine350ccan be further enabled to assign rules based on cost. For example, the cost of quality enforcement can be high, as discussed below, and limits can be placed on the desired cost. For example, given quality control rules can be associated with a given cost and limit can be placed on the total cost. Hence, a given set of rules122can be generated such that the total cost is less than a given specified cost.

In some implementations, tolerances on thresholds are also provided, however in other implementations, tolerances on measurements can be provided via quality control rule definition language module350aand/or interpretation engine350b, for example via an interaction with each module350a,350bvia browser240.

In the column labelled “Frequency”, a frequency that the associated rule is to be checked is applied. For example, Rule 1 is to be applied to “Every 10 Units” while Rule 7 is to be applied every 60 minutes. Hence, it is appreciated that the frequency that a given rule is to be applied can be expressed in any suitable format and in suitable units (i.e. checks per unit of time, checks per number of units produced or the like).

From a comparison of Rule 1 and Rule 2, it is appreciated that both Rule 1 and Rule 2 are quality control rules for checking the colour of the logo in graphics509. However, in Rule 1, it is presumed that an entity103can measure colour (e.g. using a camera device and/or a colorimeter), while in Rule 1 it is presumed that an entity103has been provided with a sample logo against which the logo in graphics509can be visually compared. Hence, quality control rule set123can account for differences in quality control data collection capability at different entities103. Furthermore, as will be described below, different subsets of quality control rule sets123can be provided to different entities103as quality control rules122based on their respective capabilities. As will further be described below, a given rule and/or quality control rules122can be further normalized based on local data associated with a respective entity103. Similarly, a given rule and/or quality control rules122can be dynamically adjusted based on local data associated with a respective entity103.

It is appreciated that rule sets123and/or rules122can be developed via interaction with rules specification interface250aand/or browser240. It is further appreciated that in implementations where modules250are located at device111, rule sets123and/or rules122are provided to computing device112, for example via links116and network115for storage in database132, as depicted inFIG. 6, which is substantially similar toFIG. 1, with like elements having like numbers. WhileFIG. 6depicts device111transmitting rule sets123and/or rules122to device112, it is appreciated that in cloud computing environments device111accesses rule specification interface250aview browser240, rule sets123and/or rules122are received at device112via browser240as each rule is developed and specified.

It is further appreciated that while rule sets123and rules122are depicted as being separate elements in the figures, in some implementations rules122can be designated as a subset of rules sets123using flags in rule sets123. For example in Table 1, Rules 1, 2, and 4 to 7 can be designated as rules122afor entities103that have a camera device and/or colorimeter for electronically measuring colour. InFIG. 6it is presumed that entity103ais an entity enabled to measure colour electronically. Similarly, Rules 1, and 3 to 7 can be designated as rules122bfor entities103that check colour of logo in graphic509through a visual comparison with a sample logo provided to such entities103by entity101. InFIG. 6it is presumed that entity103bis an entity where such a visual comparison occurs rather than an electronic inspection.

With further reference toFIG. 6, device112can process rule sets123and/or rules122according to local data601associated with each respective entity103.

For example, as depicted inFIG. 6, each entity103can transmit respective local data601(e.g. entity103atransmits data601aand entity103btransmits data601b) to computing device112via network115and any appropriate link such as links116c, dor the like. Further, it is appreciated that data601originates from any suitable combination of communication devices associated with respective entities103. For example, in addition to device113, each entity103can comprise a suitable computing device (not depicted) for interacting with device112. In these implementations, the respective computing devices can be enabled to provide local data601to device112, for example via a browser application and/or a web interface similar to that described above with respect to browser240and device111.

A non-limiting example of local data601can include additional rules local to a respective production line105. For example, while quality control rules in table 1 are particular to the final state of product500, an entity103contracted to produce product500can desire to include further quality control rules related to conditions at a respective production line105. Hence, with respect to entity103a, which is assumed in these examples to have a production line105athat comprises a conveyor belt, examples of such a further quality control rules that can be provided in local data601aare provided in Table 2:

Table 2 is similar to table 1 as describe above, however rules in table 2 are local to entity103a. For example, as production line105aincludes a conveyor belt and entity103ahas quality control Rule 1 to ensure that the conveyor belt is clear of previous product. While Rule 1 is important to entity103aas a contracting manufacturer, entity101as the brand owner has no need to set Rule 1; indeed, entity101may have no knowledge of specifics of production line105aand assumes that entity103awill take precautions to prevent cross-contamination of product500with other product produced by entity102.

Similarly, Rule 2 is particular to entity103awhich performs colour checks using a colorimeter (e.g. device113a-1).

Local data601bcan hence include a list of quality control rules particular to entity103b, for example a rule to generically “Remove previous product” prior to each production run. For example assuming entity103ahas a conveyor belt in production line105a, and entity103bdoes not have a conveyor belt, but rather manually transports components for producing product500between tables where different tasks are performed, then a Rule to clear a conveyor belt, as in Table 2, would be irrelevant to production line105b. While such a rule to clear a conveyor belt could be set by entity101in Table 1, such a rule could never be met by production line105band/or would filtered out of rules122b.

Further non-limiting examples of local data601can comprise production rates. For example, due to the conveyor belt, production line105acan have a production rate that is larger than production line105b. In specific non-limiting examples, it is assumed that the production rate of production line105ais twice as fast as the production rate of production line105b(e.g. 100 units per hour for production line105aand 50 units for hour for entity production line105b). Hence, local data601acomprises a production rate of 100 units per hour and local data601bcomprises a production rate of 50 units per hour.

Yet a further non-limiting example of local data601can comprise a list of devices113associated with a given entity103. For example, local data601acan include indications that device113a(i.e. a mobile computing device413) and device113a-1(i.e. a device for electronically measuring colour, such as a camera and/or a colorimeter) is at production line105a. Similarly local data601bcan include an indication of device113b.

In any event, local data601is provided to computing device112which can then produce respective rules122a,122bby processing rule sets123and/or rules122and/or local data601.

Furthermore, device112is enabled to normalize rules122based on local data601associated with each respective entity103. For example, consider that production line105ais appreciated to have a production rate that is twice that of production line105b. Hence, in order to maintain similar quality standards between production lines105, the frequency of temporal checks in quality control rules for production line105acan be doubled, as described below with reference to Table 3.

In another non-limiting example of normalization, tolerances on threshold values can be adjusted based on local data. For example, in implementations where a product is being produced that requires filling different size bottles with a liquid using respective nozzles at each respective production line105(e.g. the production lines have been reconfigured to produce bottles of shampoo), the tolerance can be normalized based on the size of the bottles being filled, a size and/or type of nozzle, or the like.

Indeed, it is appreciated that other types of normalization of rules122are within the scope of present implementations.

Further, quality control data from local data601can be incorporated into respective rules122a,122b. For example Table 3 depicts a rule set122aassociated with entity103aand/or associated devices113:

It is appreciated that Table 3 is similar to Table 1, with Rule 3 of Table 1, omitted. Further, the remaining rules are adjusted based on production rates provided in local data601to ensure that the quality control checks that are performed at production line105awill be similar to the quality control checks performed at production line105bsuch that a similar amount of product is checked at each production line. Hence, while Rule 5 of Table 1 is to be performed every 30 minutes according to Table 1, in Table 3 the equivalent rule 6 is performed every 15 minutes to take into account the relative difference in production rates between production lines105.

Further Table 2 is now incorporated into Table 3 as Rules 1 and 2 as each of these rules are to be performed prior to a production run.

Hence, in general, it is appreciated that Table 3 represents a list of quality control rules122aprovided to entity103ato control quality control of product500on production line105a.

However, it is further appreciated that in some implementations, the threshold values need not be included in data122aas the test for whether or not a particular quality control rule has been failed is performed at device112, as will be described below.

Similarly, Table 4 can be provided to entity103bas rules122b:

It is appreciated that Table 4 is similar to Table 1, however with a new Rule 1 inserted to “Clear previous product”, “Before each production run”, as described above. In addition, the frequency of checks is not adjusted as the rules in Table 4 are not normalized, but rather act as the data set against which data122ais normalized.

In any event, it is appreciated that Table 4 represents a list of quality control rules122bprovided to entity103bto control quality control of product500on production line105b, and that the two data sets122a,122bare normalized.

It is yet further appreciated that in some implementations, device112does not perform such normalization. Rather rules122a,122bare respectively associated with entities103a,103bas subsets of rule sets123. Similarly, in some implementations, rules122a,122bare not adjusted according to local data601, and indeed in these implementations local data601may not be provided to device112.

Rules122a,122bcan be further used to populate forms415and/or instructions417. In some implementations Rules122a,122bcan comprise forms415and/or instructions417: for example rule sets123and/or rules122and/or rules122a,122bcan be generated as items that can be used to populate forms415and/or instructions and provided to respective entities as rules122a,122b.

It is further appreciated that, in some implementations, forms415and/or instructions417can be provided to respective devices113, such that the forms415and/or instructions417are processed by and remotely available to devices113. However, in a cloud computing environment, forms415and/or instructions417are accessed by devices113via browser440.

Attention is directed toFIG. 8which is substantially similar toFIG. 1, with like elements having like numbers, however elements of entity103aand alerting rule engine350chave been emphasized to illustrate certain aspects of certain implementations, as will now presently be described. Specifically, it is appreciated that as product500advances along production line105a, devices113aare instructed to provide portions of forms415at times determined by clock device430and/or local data collected from production line105asuch that quality control checks defined according to the rules in Table 3 are performed in timely fashion.

For example, attention is directed toFIG. 9which provided a non-limiting example of a portion of a forms415provided in a Graphic User Interface (GUI)900at display426of device113a(i.e. a mobile communication device415) provided to collect quality control data414afrom device113a. It is appreciated that as the production run is not started, GUI900is prompting confirmation of Rules 1 and 2 of Table 3. While GUI900depicts radio control buttons for indicating whether or not certain conditions have occurred, it is appreciated that the format and/or controls of GUI900are not to be considered particularly limiting and that any suitable format and/or controls are within the scope of present implementations. For example, GUI900can include any suitable combination of radio control buttons, checkboxes, data entry fields (e.g. for receiving text data), or the like.

Furthermore, quality control data114a-1can be collected either automatically by device113a-1or under manual operation of device113a-1.

Once, data414is collected, data414can be transmitted to device112, by either device113aand/or device113a-1for processing using alerting rule engine350cand as will now be described with reference toFIG. 10.

Attention is now directed toFIG. 10which depicts a method1000for automatic quality control using a plurality of computers. In order to assist in the explanation of method1000, it will be assumed that method1000is performed using system100. Furthermore, the following discussion of method1000will lead to a further understanding of system100and its various components. However, it is to be understood that system100and/or method1000can be varied, and need not work exactly as discussed herein in conjunction with each other, and that such variations are within the scope of present implementations.

It is further appreciated that method1000is performed by device112, for example by processing modules350.

At block1001, database132for storing quality control rules122for producing product500is maintained, as described above. It is further appreciated that database132is maintained by device112associated with second entity112which has been contracted for maintaining quality control of product500. It is yet further appreciated that product500is being produced by a plurality of production lines105associated with respective third entities103.

At block1003, quality control data414is received from data collection devices113at each of the plurality of production lines105, each of the data collection devices113enabled to collect quality control data114for product500. For example, as depicted inFIG. 8quality control data414ais received from device113aand quality control data414a-1is received from device113a-1associated with production line105a, while quality control data414bis received from device113bassociated with production line105b. It is appreciated, that data414can be transmitted to device112whenever a new set of data is collected via a device113. Alternatively, data414can be collected for a given period of time and transmitted to device112periodically. However, as can be appreciated, the more frequent the transmission of data414, the more quality control becomes a “real-time” process.

Returning toFIG. 10, at block1005, quality control data414is compared with quality control rules122, at device112, for each respective production line105. For example, data414aand data414a-1are compared to rules122a, and data114bis compared to rules122b. The comparison can occur via alerting rule engine350c, as depicted inFIG. 8. Furthermore, in some implementations, quality control data414is stored at database132.

When data414meets the criteria in rules122(e.g. data has been collected, thresholds are met within given tolerances etc., in accordance with the rules as described above), then further quality control data414is received at block1003.

However, when data414fails to meet criteria in rules122, at block1007, alerting engine350triggers at least one quality control event. For example, a notification810of a quality control event failure can be provided to device via dashboard module250b. In some implementations, notification810is transmitted via network810for processing by device111, while in other implementations, transmittal of notification810occurs via access of dashboard application250bat device112via browser240. In some implementations, the type of notification810and/or when and/or where notification810is transmitted is determined by notification rules specification platform250c.

Alternatively, in some implementations, method1000can further comprising triggering at least one further quality control event when quality control data414passes at least one of quality control rules122. In other words, between block1005and block1003, can be a block similar to block1007pertaining, however, to passing a rule122rather than failing a rule122. An example of a quality control event that occurs upon passing a rule122could be a notification to entity101and/or an associated computing device, indicating that the rule122has been passed. Other quality control events that occur upon passing a rule122are within the scope of present implementations.

In yet further implementations, notification810can be provided to at least one entity113. For example, returning to the example product600, alerting rule engine350ccan determine from data113a-1that the colour of logo in graphic509fails Rule 3 of Table 3, (i.e. the colour of the logo is outside of the specified range logo and is hence the wrong colour). Hence, a notification810acan be provided to entity113aindicating that the inventory of blister packs507is to be quarantined. If a serial and/or lot number is provided in data113a-1, then notification810acan indicate that blister packs in that lot number is to be quarantined. Further, another notification810bcan be provided to entity113bindicating that the frequency of quality control checks on the colour of logo in graphic509is to be increased and/or that blister packs507in the serial and/or lot number are to be quarantined. A further notification can be sent to a supplier of blister packs507. When the frequency of quality control checks is changed, it is appreciated that the associated rule is updated at the appropriate device810. In other words, a quality control feedback loop is implemented, not only for a given production line105where the failure occurred, but for other production lines105. Hence, even though production of product600is being performed at different production lines105, uniform quality control rules can be applied across all the production lines, with data113afrom a first production line105afeeding back into second production line105b.

Non-limiting examples of at least one quality control event can hence comprise at least one of: notifying first entity101of a failure of quality control rules; notifying a respective one of third entities103associated with the failure; a recall order; a change in quality control rules associated with at least one of third entities103; updating data collection parameters at data collection devices113; an order to quarantine inventory that does not meet quality control rules; marking down a quality score of respective one of third entities103associated with the failure; and issuing a remedial action order to correct for the failure. Other examples of quality control events are within the scope of present implementations. Other examples include, but are not limited to: an order to modify defective inventory in some fashion (e.g. to make it acceptable again and/or bring the defective inventory back into specification, such as replacing the logo/graphics509on blister packs507with a new logo/graphic509); an order to replace and/or supplement a defective component with another component; notifying an original maker of the defective component of the issue; notifying a fourth entity of the failure (e.g. the original maker, or the like); an order to destroy defective inventory; and an order to return/transport defective inventory to another entity, such as repair shop or a recycling facility.

It is appreciated that issuing a recall order can occur when product that has failed a quality control rule at one production line105has already been shipped at another production line. For example, returning to the example of a logo in graphic509being the wrong colour, when the problem with the colour is determined at a first production line105, it can be determined that blister packs507of the same serial code family have already been shipped from another production line105. Hence, the recall order can be triggered based on the problem found at the first production line105.

Alternatively, if product has not been shipped and/or it is determined that existing inventory has a similar serial code as the inventory and/or product which failed the quality control rule, an order to quarantine inventory and/or product having similar serial codes can be issued.

In some manufacturing environments, contract manufacturers are provided with a quality score. Hence, in these environments, the failure can trigger marking down a quality score of respective one of third entities103associated with the failure. Such a markdown can trigger further remedial action, such as adjusting quality control rules122for the given entity103(e.g. tightening thresholds, tolerances and/or increasing frequency of quality control checks).

Furthermore, a quality control failure of given inventory can be further used to rate a supplier of parts/inventory and/or issue warnings, notifications and the like to suppliers via notifications similar to notifications810and/or by notifying entity101who will in turn notify the supplier(s).

With regard to a change in quality control rules associated with at least one of third entities103, when a quality control rule122has been failed, rules122,122aand/or122bcan be updated to be more stringent and/or to be more frequent. For example, a given rules can be changed from checking 1 in 10 products to checking 1 in 5 products. Alternatively, threshold values and/or tolerances could be changed (e.g. made smaller). Such a change can be implemented either by including a command to update a given rule in notification810aand/or810b, and/or by issuing separate commands1110, as inFIG. 11to update data collection parameters at devices113, such as changing forms415and/or instructions417.

Furthermore, it is appreciated that at least one quality control event can triggered at a first one of the third entities103based on given quality control data414from a second one of the third entities103indicating failure of at least one of the quality control rules122, as described above.

Indeed, it is appreciated that issuing any suitable remedial action order to correct for the failure is within the scope of present implementations. For example a notification can be sent to a supplier of blister packs507.

In some implementations, method1000can further include adjusting at least one of quality control rules122for a respective production line105based on local data601at the respective production line105. For example, adjusting at least one of quality control rules can comprise adjusting a threshold and/or adjusting a frequency for applying the quality control rule, as described above with regard to normalizing quality control rules between production lines105.

In some implementations, method1000can be understood as a feedback loop for controlling quality across a plurality of production lines. For example, block1007can return to block1003. Furthermore, a quality control event triggered at block1007can include triggering an event at a second production line105based on a failure at a first production line105. Hence, despite the same product being manufactured at different production lines, a uniform quality standard can be applied to the product.

Such a feedback loop can further be applied to normalizing quality during a production run as local data601evolves. For example, consider a given production line105with a three day production run in which the production rate increases each day (e.g. the workers become more efficient as they learn how to manufacture a product). Local data601, such as production rate, can be collected periodically and transmitted to device112, which in turn causes the quality control rules122to be adjusted “on-the-fly” based on local data601. For example, as the production rate increases, the frequency of quality checks can be increased (e.g. by updating instructions417by transmitting updated commands to device(s)113) accordingly. Similarly, when production rate decreases, the frequency of quality checks can be decreased accordingly.

Various advantages will now be apparent. For example, by using devices113to perform quality checks electronically, and by implementing an automated notification system that allows response to dips in quality with remedial action before further quality issues are encountered, costs are reduced for: scrap, rework (both materials and labour), additional materials costs, inventory overhead, overhead for extra time and administration, recall costs, decreased sales due brand erosion from poor product, service and support. Further, costs are further reduced by implementing a quality feedback loop across remote production lines, such that quality control failures at one production line can be fed back into other production lines.

In other words, present implementations, results in reducing the cost of quality in a network of manufacturing suppliers, each using a different process to produce the same finished good (i.e. product). Such advantages become further apparent in light of the following equations:

D=Number of defects that existed in a given production run;

C=Number of checks performed in the given production run;

P=Number of units produced in the given production run;

DC=Average number of checks that are actually done upon a unit with a defect in it in the given production run;

PS=Probability that a check performed on a defective unit will actually find the defect; and

DF=Average number of defects found in the production run.

From these equations it is appreciated that as the number of checks C increases, the number of defects found, DF, increases. Further, as the number of units produced P increases, or similarly, the rate of production increases, a greater number of defects D are produced, and checks C need to increase accordingly.

However there is also a cost to performing checks. The Cost of Quality (CoQ) includes both “appraisal costs” and “failure costs”. Appraisal costs include the cost to perform an inspection whether they are machine setup and operating costs, and/or labour costs for manual inspections. Failure costs range widely from “internal failure costs” such as the costs to produce another unit that is not defective (e.g. replacement materials, overhead, and labour) and “external failure costs” when a defect is not caught before it is released from manufacturing (e.g. recall costs, customer satisfaction, regulatory compliance costs).

Because production rates, machine types and efficiencies, labour rates and skill levels, and other conditions vary across companies the optimal approach to maximizing quality while minimizing costs is different in each environment.

Present implementations reduce such costs across the different manufacturing processes used at different contract manufacturing and/or packaging companies—even if it is for producing the same finished good/product due the automation of the collection of quality check information, which is processed this through alerting rule engine350cenabled to respond automatically in real-time to changing results of quality check procedures across different production lines, thereby improving the quality of finished goods.

Hence, by applying present implementations in a distributed manufacturing environment various advantages are evident, even in extraordinarily short production run durations (not uncommonly only a few hours) where it is otherwise very hard to track the relevant information accurately, let alone respond to it in time to make adjustments accordingly:

1. As the manufacturing processes and rates will be different at each environment/production line, to properly ensure consistent quality, quality standards can be enforced differently both by adjusting the number and type of quality control rules for each line and by normalizing rules across different lines;

2. As the cost of ensuring product quality will vary in each environment, the impact of this cost can be factored into decisions about quality and line productivity automatically.

3. As production is often performed across different companies, when a quality issue is discovered in one company (e.g. in a subcomponent used in each of the different contract packagers), adjustments can be immediately provided across the network of contract packagers through the quality system in response to this quality issue (e.g. increasing frequency, changing tolerances, or enforcing a hold on a product).

4. Immediate/real-time feedback of changes in quality factors, more granular/detailed checking, and opportunities to make adjustments for changing quality across a disparate group of contract packagers.

A non-limiting example is now provided to illustrate various advantages of present implementations.

Electronics company “Western Electronics” has contracted two contract packagers ABC and DEF to produce the same finished good: an electronics device packaged with a cable and batteries in a plastic blister pack with special promotional graphics (e.g. as inFIG. 5).

ABC begins producing the promotional blister pack. On the second day of production a quality check fails because the color of the Western Electronics logo in one case of blister packs is wrong—it does not match the specified color parameters programmed in the image processing device used by ABC.

However, a suitable data collection device113automatically reports the failed check to device112where the failed check is recorded in database132and alerting rule engine350cidentifies that the colour being within a given specification (e.g. between two thresholds) check is a hard requirement (e.g. compares data414with rules122): i.e. the logo cannot be the wrong color. In response to the failure, alerting rule engine350ctriggers an appropriate action or actions.

For example, a recall order is issued to the retailer who received the shipment of the first day of ABC's production.

Furthermore, by accessing and/or interfacing with and/or integration with an production management system (e.g. as disclosed in Applicant's PCT Patent Application having a publication number WO 2010/060181, having an international application date of Mar. 3, 2010 and entitled “SYSTEM, METHOD, AND COMPUTER PROGRAM FOR MANUFACTURING ESTIMATION PRODUCTION ASSEMBLY AND INVENTORY MANAGEMENT”, which claims priority from Applicant's U.S. Provisional Application of the same name, having Application No. 61/118,567, and filed Nov. 28, 2008), altering rule engine350cdetermines that Contract Packager DEF has also received the same lot code of blister packs. However DEF has not yet noticed the issue, so (under the authority of Western Electronics) altering rule engine350ctriggers a quality control event which causes this inventory to be set with a special “quarantine” status automatically so DEF cannot use this material in production. In the present example, it is assumed that DEF is a new supplier and is not as familiar with the color rules. Further, it is assumed that DEF is performing the color check manually, for example by checking the colour against a sample logo.

It is appreciated that further integration with the production management system is contemplated, for example to issue new purchase orders for new inventory, and the like. Other actions which can be automatically triggered in the production management system by alerting rule engine350care within the scope of present implementations. Furthermore, in some implementations, any suitable combination of modules250,350and/or database132can be components of the production management system.

Device112, either through altering rule engine350cor another suitable module, follows a rule to mark down the quality score of the manufacturer of the blister pack so that checks of their products will be required more frequently effective immediately. Hence, in addition to taking a remedial action at an entity113, a remedial action can be further taken for a supplier or the like.

Device112, either through altering rule engine350cor another suitable module, notifies the project manager at Western Electronics of the issue, and further confirms that the specified remedial action has already been taken. A purchase reorder for a new batch of the blister packs can also be created automatically, pending review and approval. An estimate of the project delay and cost of this quality issue can further be provided automatically.

Western Electronics can now review all of this information together and see that the cost of the recall will be significant enough that they will have to require DEF to check logo colors on every new lot code which may increase costs, but will prevent another even more costly recall activity.

Hence, it is appreciated from this non-limiting example that present implementations can be integrated with any suitable system for issuing recall orders, purchase reorders, and managing suppliers. Indeed, in some implementations, device112and/or modules350and/or modules250are each modules of such a system.

It is yet further appreciated that reporting functions of present implementations can include any suitable level of complexity. For example, as in the previous example, a report of the remedial actions that occurred automatically can be provided to entity101, as well as estimates project delays and additional costs. Further, changes to rules122for a given entity103can occur after a review of such a report, and the changes can be programmed manually for later distribution to entities103and/or devices113.

It is further appreciated that data from system100can be used to determine quality control metrics for a product and/or a contract manufacturer/packager and/or a supplier and/or any other suitable entity or product. For example, brand owners often want to use quality check data, for example the percentage of checks which have passed/failed for a particular contract manufacturer/packager, to derive higher level metrics to determine efficiency and or effectiveness of the contract manufacturer/packager, In some implementations, a metric called “True Efficiency” (also known as “Overall Equipment Effectiveness”) can be derived, at least in part, from the quality check data. Such higher level metrics can be uses to evaluate how well various suppliers, manufacturers and/or packagers are performing relative to each other, as well as whether or not they are confirming to given up to this True Efficiency standard that is being enforced.

Those skilled in the art will appreciate that in some implementations, the functionality of devices111,112,113can be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components. In other implementations, the functionality of devices111,112,113can be achieved using a computing apparatus that has access to a code memory (not shown) which stores computer-readable program code for operation of the computing apparatus. The computer-readable program code could be stored on a computer readable storage medium which is fixed, tangible and readable directly by these components, (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB drive). Alternatively, the computer-readable program code could be stored remotely but transmittable to these components via a modem or other interface device connected to a network (including, without limitation, the Internet) over a transmission medium. The transmission medium can be either a non-wireless medium (e.g., optical and/or digital and/or analog communications lines) or a wireless medium (e.g., microwave, infrared, free-space optical or other transmission schemes) or a combination thereof.