Aggregated Data Shared Between Enact Tenants
Enact can be the “language” that everybody in your company speaks—that is, everyone using a common system, while still controlling their own data—moving away from older forms of data sharing (PDFs, spreadsheets, COAs, etc.) and providing immediate and accountable data sharing between manufacturers.
Enact now includes a new option known as Data Connections > Enact Connections found under the Data Management submenu, which allows daily aggregated records to be continuously copied from one Enact tenant to another—particularly from a supplier or vendor to a purchaser. The records are visible in the receiver's (purchaser's) tenant using their own naming conventions and can be reported on with aggregated dashboards (just like their own data):
The diagram below helps illustrate this new functionality:
Note: The Publishing function, originally found in the Access menu, has also been moved to the External Connections section within the Data Connections option, as pictured below:
- This function gives a purchaser insight into a supplier’s compliance and visibility across the supply chain. And, at the same time suppliers can show evidence of compliance and better assurance of quality.
- Being able to receive quality data directly from vendors can be part of a purchaser's contract with them so they can see the exact performance of what they're receiving and having a more proactive approach.
- You can compare vendors to their own quality benchmarks, or even compare vendors to each other, but at the same time, vendors can still maintain their own Enact tenants and data and choose the data to share (key features, operations, product lines, etc.).
Collapse Subprocesses on the Process Information Tile
Operators never need extraneous information or steps to perform to do their jobs. Keep it simple, keep it fast. For instance, on the Process Information tile, why would operators want or need to select from an entire list of processes when they only really need to see relevant ones? This new process-level option we’re introducing in Enact determines whether subprocesses should be listed separately on the tile (current behavior) or collapsed and hidden under the parent process (new option).
For this to take place, a new option, Collapse Subprocesses on Process Information tile, can be enabled on the Process landing page:
- For individual-type subprocesses (e.g., molds), the existing behavior makes sense, as the subprocesses are being brought in and out, creating different parts, doing separate things as separate times. It makes sense to control the individual production assignments, timed data collections, etc., separately.
However, for parallel-type subprocesses (e.g., fill heads), all subprocesses are doing the same thing. There may be therefore no benefit to seeing them listed separately with a collection of unused configuration options.
Control Limits Bulk Update
Currently, the process of individually generating or updating control limits is manual and time-consuming. This becomes unmanageable when there are hundreds of control limits that need to be generated or updated at once.
Enact now facilitates the update or generation of control limits in bulk by any admin. This new feature—known as Bulk Create Control Limits—is found on the Control Limits page (pictured below). It enables users with appropriate permissions to create control limits for a selection of multiple data streams at once and preview the changes before committing to them.
- When control limits are not updated, your control charts could be raising false events/notifications. This functionality enables users to better utilize Control Charts as a tool for their decision making.
- This new feature maintains the current rules and functions that already exist for calculating control limits based on a single stream.
Edit Subgroup/Checklist Data Separately from Data Collection/Checklist Configuration (role permissions)
Let’s say that you, as the system admin for your company, want to grant permission to a user to only edit subgroup (or checklists) without
allowing them to edit the data collection or checklist settings. You might want the role to edit collected data and avoid data collection configuration changes—this is what this release will provide by having separate permissions.
To help separate/clarify these role permissions:
- Checklist – Edit Collected Data (edit the checklist collected data)
- Checklist – Edit Configuration (edit the checklist configuration from the landing page)
- Data Collection – Edit Collected Data (edit the collected data)
- Data Collection – Edit Configuration (edit the data collection configuration from the landing page)
- The more granular your role permissions settings, the better the software works for your users. This new functionality helps admins provide their users with more precise permissions and ensure data integrity.
New Language – Italian
If your company employs workers who speak various languages, and you want to make sure operations go smoothly—that is, you don’t want any hiccups due to language difficulties. How do you accomplish that? With having the software display in their native language.
Enact now has a built-in interface translation provided by InfinityQS for the Italian language apart from all the other languages Enact currently supports. The current list includes: Danish, English, French, German, Hindi, Portuguese, Spanish, Swedish, Vietnamese, Norwegian, and Dutch.
Users can select Italian as their preferred language in My Settings
under Preferred Language.
Italian speaking users will then be able to see all of Enact’s standard fields in their native tongue.
- When users, particularly operators, can view the interface in their own language, it increases comprehension. Misunderstandings and errors that might occur if the interface were in a language with which they weren’t comfortable or familiar are eliminated.
Automatic Process State Transition from Pause to Stop
Paused timers in Enact have a fixed lifespan of 24 hours. Any paused sampling requirement that reaches the expiration time becomes a missed
requirement; however, the process state remains “Paused.” This behavior inhibits “run-once” requirements (e.g., start-up checks) to be triggered after coming out of an expired Paused state—unless the user manually
selects the Stop process state.
With this enhancement, timers that have been paused longer than the default expiration time (again, 24 hours) will automatically change to the Stop process state. This process state transition will also be recorded in the application logs and will not require any separate configuration from the user.
- This new functionality will reduce confusion for operators: They will no longer have to manually select the Stop process state before a “run-once” sampling requirement can be triggered again. For example: When the pause expiration time has elapsed, operators can select the process state for start-up checks, and those checks will now be triggered without them having to manually select the Stop process state.