After years of working across quality, safety, security, service, food safety and enterprise transformation, I am still often asked a deceptively simple question: “What exactly do you do?” The title management systems consultant is accurate, but it does not fully describe the work.
I could also describe myself as a PM/BA in ERP and digital transformation programmes. Yet that is only one part of the role. I am usually invited into an organisation when the problem is still fragmented, requirements are unclear, functions see the situation differently and no one has yet connected the whole picture.
My work is to identify the system behind separate operational symptoms; translate governance objectives into processes, accountabilities, data and controls; connect international standards with operating reality; turn business needs into requirements that technology teams can build; and stay engaged until the system can operate, be controlled and continue to improve.
A role close to the operational front line
In technology, this way of working has similarities with the Forward Deployed Engineer (FDE): a specialist positioned close to the client’s front line to understand problems, develop solutions and put them into practice. My scope, however, extends beyond technology.
I work at the intersection of Governance – Management Systems – Operations – People – Sustainability – Digital Transformation. SoConn describes this as a Forward-Deployed Transformation Architect. It is not presented as a standardised profession; it is a practical definition of the responsibility to see the whole system, connect specialist disciplines and help design become operational practice.
Organisations rarely begin with a clear requirement
Complex assignments seldom arrive as a complete specification. They surface through practical symptoms:
- Documents are dispersed and version control is weak;
- Incidents are recorded but corrective actions are not followed through to closure;
- Several functions participate in a process, but accountability breaks between them;
- Data is manually consolidated across spreadsheets;
- An ERP offers many functions but does not reflect how the organisation actually operates;
- ISO certification exists, while the management system contributes little to decision-making;
- ESG remains a reporting layer rather than a structure of data, ownership and decisions;
- Training activity is high, but competence after training is not demonstrated;
- The technology provider waits for requirements while users do not yet know how to articulate them.
Addressing each symptom separately may create more forms, procedures or software while leaving the underlying problem intact. The first need is not to select technology. It is to frame the right problem.
Starting where the problem actually occurs
I do not begin by asking which standard or software the organisation wants. I begin with the result it needs, the operational constraint, the data used for decisions, the point where accountability breaks, the risks that remain unseen and the conditions in which the solution must work.
- Understand context: objectives, operating model, stakeholders and maturity.
- Diagnose the problem: current state, constraints, root causes and risks.
- Architect the system: target model, accountabilities, data, controls and roadmap.
- Standardise and specify: future processes, business requirements, acceptance criteria and exceptions.
- Implement and verify: align stakeholders, test, accept and embed the solution.
- Sustain and improve: build capability, use performance data and maintain learning cycles.
This is not consulting from outside the organisation. It is co-creation where the system will be used.
Technology is one component of the system
Software cannot resolve unclear accountability, illogical processes, ownerless data, inconsistent approval criteria, unidentified exceptions or unprepared users. If these foundations remain unresolved, technology merely digitises existing fragmentation.
In an ERP programme, my role therefore goes beyond collecting user requests and passing them to developers. It requires understanding the operating model, defining scope, analysing the current state, co-designing future processes, clarifying responsibility and data, governing change and establishing acceptance criteria.
The critical questions sit where governance, operations and technology meet: Which decisions must the system support? Which processes must be redesigned before they are digitised? Who may initiate, review, approve and close a record? How are exceptions handled? What must be true before the solution is accepted and released?
I do not “put ISO into an organisation”
When working with ISO 9001, ISO 22000, ISO/IEC 27001, ISO/IEC 20000, HACCP or other management frameworks, the objective is not a documentation set created for certification. Standards create value only when they become a proportionate operating mechanism linking context and strategy; processes and accountability; risk and control; data and decisions; assurance and improvement; competence and performance.
Across aviation, aviation technology and airport-lounge services, I have helped design and implement integrated architectures spanning quality, safety, security, information security, IT service management, food safety, supply chains and operational capability. Their common denominator is not the number of standards. It is the discipline of seeing the organisation as one system.
ESG must also be built as a governance system
ESG should not begin with an attractive report. It should begin with materiality, ownership, data architecture, calculation methods, evidence, risk governance and leadership review. Without these foundations, ESG remains an information layer outside the business.
My principle is: build the ESG system before telling the ESG story. That system includes governance architecture, materiality assessment, data controls, greenhouse-gas inventories, MRV, accountability, supply-chain management, management review and readiness for independent assurance.
In F&B, standards must reach the point of service
A food-safety system cannot live only in a HACCP manual. It must reach receiving, storage, preparation, cooking, hot holding, chilling, display, service, cleaning, allergen management and incident response.
A temperature limit matters only when someone is accountable for measuring it, the device is suitable, data is recorded, deviations trigger an alert and the required action is clear. A process exists only when people can perform it under shift patterns, variable passenger volumes and real service pressure. System design must therefore connect directly with training and demonstrated competence.
AI creates new possibilities, but it does not replace systems thinking
AI can support requirement analysis, process modelling, prototyping, control logic, data analysis, agent design, testing and repetitive automation. But the ability to create quickly is not the same as the ability to create correctly.
The important question is not “What can AI do?” It is: In this organisation, at this point in time, where should AI participate, using which data, within which boundaries and under what controls? Some problems need AI. Some need workflow automation. Some require process redesign before technology. Some decisions must remain human.
The value lies in connecting different worlds
In a transformation programme, each party holds part of the truth. Leaders understand direction and commercial pressure. Operators understand daily reality. standards specialists understand requirements and controls. Technology teams understand architecture, data and platform constraints. Vendors understand their products.
Without a connecting role, an organisation can receive a solution that is technically correct but operationally wrong; compliant on paper but difficult to use; or adequate today but unable to scale. Sometimes the greatest value is not an immediate solution, but the independence to say: “We are solving the wrong problem.”
Not replacing specialists — designing how expertise works together
I do not replace software engineers, finance specialists, environmental experts or process owners. My responsibility is to design the structure through which those capabilities work coherently: boundaries, interfaces, accountabilities, inputs, outputs, control criteria and decision mechanisms.
This requires clear distinctions between architecture and configuration; business requirements and technical solutions; advisory responsibility and decision authority; implementation governance and software development; certification and the actual effectiveness of the system.
A capability set built through practice
- Systems thinking: connecting strategy, people, processes, data, technology, risk and results.
- Governance architecture: translating objectives into accountability, authority, controls, measures and improvement.
- Standards and compliance: understanding international requirements without applying them mechanically.
- Operational understanding: observing real work and designing for operating conditions.
- Business analysis and programme governance: translating needs into future processes, requirements, acceptance criteria and delivery roadmaps.
- Technology literacy: understanding data, integration, access control, testing and AI well enough to evaluate solutions.
- Human collaboration: asking, listening, aligning differences and creating a shared language.
From consultant to co-creation partner
Organisations increasingly need more than reports that stand apart from implementation. They need a partner who can move with them from problem to solution, design to operation, and operation to improvement.
This is especially important in Greenfield programmes, where a new model, facility or system is being created from its first foundations. Greenfield work creates an opportunity to align governance, operations, standards, data, technology and human capability from the outset through Prevention by Design.
How I define my work
I am Nguyen Ngoc Thanh Hoa, CQP MCQI — Founder of SoConn Vietnam, an independent advisor and systems architect working across integrated governance, quality, aviation, ESG and enterprise transformation.
I do not sell a standard in isolation. I do not begin with software. I do not impose a ready-made model. I begin with the organisation’s context and objectives; establish the governance foundation; selectively apply relevant standards and good practices; and translate them into a system suited to its people, resources and operating reality.
Governance is not control — it’s connection.
Governance is more than control. It creates the right connections so the entire system can operate, adapt and develop. This is the principle that guides SoConn’s approach to co-creation.
← Return to Insights