Individual Accounts, Yet Process-Parameter Changes Still Lack Accountability: Why?

One person one account, why can't responsibility be traced after process parameters are changed?

The system has eliminated shared accounts, with each process engineer and team leader having their own username. After a batch deviation, the backend showed that a team leader had modified machining parameters overnight, but he claimed he had only asked a colleague to borrow a computer to check data. The shop floor can find an account, but still cannot determine who decided, who operated, and why the change was made.

"One account per person" is just the starting point of identity management. To trace a critical modification, personal identity, authorization scope, operation terminal, change reason, and review result must all be recorded. Missing any of these elements means the log may be complete, but the accountability chain remains broken.

For factory owners, tracing is not about finding someone to take responsibility first, but confirming whether permissions, responsibilities, and rewards are aligned. If more work means more mistakes, and less work means fewer mistakes, the operator will say "It's not my responsibility," the authorizer is unwilling to accept ownership, and anomalies will not be escalated, transferred, or closed.

1. A unique account does not guarantee the operation belongs to the user

shop-floor computers are often placed next to machines, with personnel wearing gloves and frequently changing shifts, which can affect the production rhythm through repeated logins. To save time, some do not log out, others operate on behalf of colleagues, and some write passwords on equipment. This is not necessarily intentional, but rather a mismatch between security requirements and shop-floor operations.

If management only emphasizes "no account sharing," but does not provide quick login, screen lock on leaving, and urgent task handling mechanisms, employees' most practical choice may still be to bypass the rules. The issue appears to be discipline, but the root cause is often a mismatch between process costs and permission responsibilities.

2. Key actions must record people, machines, and events simultaneously

"Person" is an authenticated operator, "machine" is a specific terminal or device, and "event" is the modification target, before-and-after values, reasons, and related work orders. Only when all three elements are present can the difference between personal operation, borrowed terminals, and system auto-write be distinguished.

General production reporting and critical parameter changes should not be subject to the same level of scrutiny. Queries and general confirmations can remain simple; however, changes to process parameters, release status, recipes, or equipment protection values should trigger re-verification and require selection of the reason for the change.

3. Permissions should be layered by actions, not just by positions

Although both are team leaders, some only need to adjust work assignments, while others genuinely need to temporarily modify parameters. Granting all permissions to a position can lead to overly broad authorization; removing all permissions, on the other hand, may result in shop-floor delays and the need to borrow identifiers.

A more practical approach is to separate viewing, suggesting, executing, and approving functions. Operators submit suggestions, authorized personnel execute them, and any changes beyond defined boundaries are reviewed by process or quality personnel. In emergencies, temporary authorization can be granted, but it should be limited to specific individuals, duration, and frequency, with automatic revocation after completion.

4. Logs should support review, not just leave traces

the factory owner conducts random checks three times a week on critical modifications: who logged in, on which terminal, what the values were before and after the change, which work order it relates to, who reviewed it, and the outcome. If logs can only answer the account and time, they are insufficient for quality traceability.

A checklist can be used for review: first verify identity and terminal, second check the change values and reasons before and after, and third confirm the authorization, review, and closure records.

Attention should also be paid to failed logins, unauthorized attempts, batch modifications, and operations outside of shift hours. Logs are not for immediate post-event accountability but to first reconstruct the facts and then determine whether the issue lies in training, authorization, interface design, or process.

5. Different factories start from different cost points

Small factories should first address the issue of unsecured shared terminals, medium-sized factories should focus on splitting key permissions and temporary authorizations, and large factories must integrate identity, work orders, and equipment logs. Security requirements cannot simply follow office practices; they must consider continuous production, reliability, and emergency response on the shop floor.

A truly traceable account system is not about having the system always display a single name, but ensuring that every critical action has a trusted identity, clear authorization, and complete context. Only by designing login convenience, permission boundaries, and change records together can responsibility be prevented from remaining hidden behind the account.

I am Huang Chaoxing, inventor of the TreeMES stack-light MES system. Follow me for continued analysis of shop-floor management and digital transformation trends in manufacturing.