Personal AI agents such as Claude Duet and ChatGPT dots work for one person: they read that person’s email, calendar and apps, and they take care of personal tasks. ProjectVIEW AI gives every business user a personal AI agent, because it inherits each user’s profile and role from ProjectVIEW ERP. So a project manager, a cost controller and a CFO each get their own AI assistant, working on the company’s records within their own role, approvals and a private environment.

What are Claude Duet and ChatGPT dots?

Both are always-on AI agents launched in autumn 2026. They run in the background on their own cloud computer and act for one user.

• Claude Duet (Anthropic, research preview since October 2026) sends a short morning brief, checks the user’s connected apps every few hours and carries out tasks. It asks before it sends, pays, signs or deletes anything.
• ChatGPT dots (OpenAI, launched in September 2026) gives each user a personal agent, called a “dot”. It works across apps such as Gmail, Google Calendar, Slack and Teams.

In short, these agents are personal assistants with good judgment. They answer a simple question very well: “What do I need to do today, and can you do some of it for me?”

Why can’t a personal AI agent run business operations?

A personal agent sees what one person sees: an inbox, a calendar, some files. However, business operations do not live in an inbox. They live in structured records that many people create over months: bills of quantities, schedules, cost codes, contracts, certificates and approvals.

Consequently, a personal agent faces three limits in project-based companies:

1. It does not know your operating model. It sees emails about a project, not the cost structure behind it.
2. It works with one person’s access. Business decisions need company-wide data, filtered by role, not one user’s mailbox.
3. It sits outside your governance. Approvals, segregation of duties and audit trails belong in the business system, not in a personal assistant.

The table below sums up the split.

How does ProjectVIEW AI become personal for each business user?

ProjectVIEW AI does not create a second set of users. Instead, it inherits each user’s profile from ProjectVIEW ERP. As a result, the AI knows who is asking and what that person is allowed to see and do, from the first day.

The AI inherits five things from the ERP profile:

1. The user account: who is asking.
2. The role: for example project manager, cost controller, procurement manager or CFO.
3. The assignments: the companies, joint ventures and projects the user works on.
4. The permissions: access at module, function, field and record level.
5. The place in workflows: which documents and decisions the user prepares, reviews or approves.

Therefore, the same question gets a different, role-correct answer. For example, ask “What needs my attention this week?”:

• A project manager sees slipping activities and open variations on his own projects.
• A cost controller sees cost codes trending over budget across her portfolio.
• A CFO sees cash exposure by company and joint venture, without line-level site detail.

This role-based assistant is live in ProjectVIEW ERP today, and you can see it in a demo on request.

In short, Claude Duet and ChatGPT dots personalise AI around a person’s private apps. ProjectVIEW AI personalises AI around a person’s business role. And because the profile comes from the ERP, there is no separate permission set to maintain, and nobody sees more through the AI than they see in the ERP.

Why does business AI need to understand each company separately?

Two contractors in the same market rarely run the same way. One self-performs civil works; the other subcontracts almost everything. One splits a project into 300 cost codes; the other uses 3,000. Their approval chains, pricing logic and joint-venture structures differ as well.

For example, both companies ask the same question: “Is the tower project overrunning?”

• Contractor A self-performs the frame. Its overrun sits in labour cost codes, because productivity on site is below the rate in the budget.
• Contractor B subcontracts the frame. Its overrun comes from variations that the site approved but nobody certified, so the client has not been charged.

A generic AI gives both companies the same, average answer. In a business with thin margins, an average answer is often a wrong answer. ProjectVIEW AI gives each company a different answer, because it traces the cause in each company’s own records.

How does ProjectVIEW ERP give the AI an accurate model of your business?

The AI is only as good as the structure it reads. That is why ProjectVIEW AI works on top of ProjectVIEW ERP, the integrated ERP built on the BoQ WBS Cost Codes framework.

• BoQ (Bill of Quantities): what you sell and get paid for.
• WBS (Work Breakdown Structure): how you plan and build it.
• Cost codes: what it costs, line by line.

ProjectVIEW ERP links these three structures in one record. In addition, its system configurator and workflow engine shape processes and approvals to the way each company works. So the AI does not guess your operating model; it reads it.

ProjectVIEW AI combines domain-specific small language models with leading large language models. The models retrieve ERP context at the moment you ask, so no retraining on client data is needed. As a result, answers reflect your latest records. Read more about ProjectVIEW AI.

Once the AI reads your structure, its agents are designed to flag cost overruns per cost code, compare subcontractor claims with measured progress, collect evidence for claims and variations, and compare new bid rates with past projects. Agents are rolled out by module and confirmed per client. See how this connects to cost control in ProjectVIEW ERP.

What happens to your data when you ask ProjectVIEW AI a question?

Operational data holds bid prices, margins, subcontract terms, payroll and claims strategy. Therefore, security has to be part of the design. Each question follows six steps:

1. You ask a question in the ProjectVIEW AI assistant.
2. ProjectVIEW AI applies your ERP user and role profile. You only reach the modules, fields and records your role allows.
3. The AI retrieves the relevant ERP records at that moment.
4. The model runs in a private environment on Microsoft Azure or on your own servers. Data is not sent to public consumer AI services.
5. You get an answer and, where useful, a proposed action. A person approves every consequential action.
6. The decision stays on record in the audit trail.

On Microsoft Azure, prompts are not used for model training. Data residency options, encryption at rest and customer-managed keys are available. DANAOS Projects holds ISO 27001, ISO 9001, ISO 14001 and ISO 20000-1. For details, see ProjectVIEW AI data security and governance.

How do personal agents and ProjectVIEW AI work together?

The two layers complement each other. A project director might use both in one morning:

1. Her personal agent prepares a morning brief, drafts replies and books a meeting with the client.
2. ProjectVIEW AI flags that two subcontract packages are trending over budget and shows why.
3. She approves the corrective action in ProjectVIEW ERP, and the decision goes on record.

In addition, ProjectVIEW ERP v12 includes an MCP connector for Claude and ChatGPT. MCP (Model Context Protocol) is an open standard that lets AI assistants connect to business systems in a controlled way. Companies that use it should connect through business or enterprise AI workspaces and check each plan’s data terms, because data leaves the private environment when an external assistant reads it.

What mistakes should companies avoid?

• Pasting operational data into personal AI tools. It feels fast, but bid prices and margins leave company control.
• Running AI on exports instead of live records. Exports go stale within days, so the answers do too.
• Starting AI before the cost structure is clean. If BoQ, WBS and cost codes do not connect, no AI can explain a margin.
• Skipping approvals. AI should prepare decisions; people should make them.

How should executives decide which AI to use for what?

Use one simple rule. If the task belongs to one person — email, calendar, reminders, personal research — a personal agent is a good fit. If the task belongs to the business — cost, schedule, contracts, cash, risk — it needs AI on your system of record, inside your governance.

A full ProjectVIEW ERP implementation takes 5 to 7 months. ProjectVIEW AI can also run on top of existing systems such as SAP, Oracle or Primavera P6, so you can start with the area that hurts most. Pricing depends on the modules, the number of users and the deployment option.

Frequently asked questions

Is Claude Duet or ChatGPT dots a replacement for an ERP AI assistant?

No. They are personal agents that act for one user across that user’s apps. Business operations need AI that reads the company’s system of record within roles, approvals and audit.

Is ProjectVIEW AI personalised for each user?

Yes. ProjectVIEW AI inherits each user’s profile, role, project assignments and permissions from ProjectVIEW ERP. So every business user gets answers and proposed actions that fit his or her role, and never sees more than the ERP allows.

Can ProjectVIEW AI work with Claude or ChatGPT?

Yes. ProjectVIEW ERP v12 includes an MCP connector for Claude and ChatGPT. Use business or enterprise workspaces and check each plan’s data terms.

Is our data used to train AI models?

On Microsoft Azure, prompts are not used for model training. ProjectVIEW AI retrieves ERP context when you ask, so no retraining on client data is needed.

Does ProjectVIEW AI make decisions on its own?

No. It prepares analysis and proposed actions. A person approves every consequential action, and the decision stays on record.

Read more: A Personal AI Agent for Every Business Role: ProjectVIEW AI

The six construction ERP systems worth evaluating in the Philippines for 2027 are ProjectVIEW ERP, SAP S/4HANA, Oracle Fusion Cloud ERP, Microsoft Dynamics 365, IFS Cloud and Acumatica Construction Edition. Large contractors, EPC companies and infrastructure developers should prioritise BoQ-based project cost control and enterprise integration. By contrast, small and mid-sized contractors usually need construction accounting and job costing first.

A practical guide to leading construction ERP solutions for contractors, EPC companies, infrastructure developers and engineering firms in the Philippines.

Why do contractors need construction ERP systems in the Philippines?

Choosing the right construction Enterprise Resource Planning (ERP) software is an important decision for Philippine construction companies. After all, they manage complex projects, rising material costs, subcontractors, equipment and operations spread across many sites and islands.

In 2027, however, contractors need more than accounting software. Instead, they need integrated platforms that connect project estimation, budgeting, procurement, scheduling, resource management and financial performance.

Three local factors make integration especially important for Philippine contractors. First, projects often span several islands, which makes site-to-head-office reporting harder. Second, public infrastructure and PPP contracts require detailed records of progress, variations and claims. Third, the finance module must handle BIR tax and reporting rules correctly. As a result, an ERP that links site data, contracts and accounting in one system reduces manual reconciliation across all three.

So here are six construction ERP systems worth evaluating, each serving different business requirements.

What are the best construction ERP systems in the Philippines for 2027?

1. ProjectVIEW ERP by DANAOS Projects

Best suited for: Large construction contractors, EPC companies, infrastructure developers and capital-intensive engineering enterprises.

ProjectVIEW ERP is a construction-specific enterprise ERP platform that integrates project execution with financial and operational management.

Key capabilities:

• Integrated Bill of Quantities (BoQ), Work Breakdown Structure (WBS) and Cost Codes
• Project budgeting, forecasting and cost control
• Procurement, subcontractor and equipment management
• Estimation, tendering and contract administration
• Integration with Primavera P6, BIM and third-party enterprise systems

Key consideration: Particularly relevant to large contractors that need detailed project-level cost control. DANAOS also has a branch office in Bonifacio Global City (BGC), Taguig, for clients in the Philippines.

2. SAP S/4HANA

Best suited for: Large construction groups requiring enterprise-wide financial management and standardised business processes.

SAP S/4HANA is a comprehensive enterprise ERP platform that companies across multiple industries use, including engineering and construction.

Key capabilities:

• Enterprise financial management and consolidation
• Procurement and supply chain management
• Asset management
• Project accounting and reporting
• Multi-company and multinational operations

Key consideration: A strong option for large diversified groups. However, construction-specific workflows may require additional SAP components, integrations or configuration.

3. Oracle Fusion Cloud ERP

Best suited for: Large enterprises prioritising financial governance, procurement and cloud-based operations.

Oracle Fusion Cloud ERP provides an integrated suite of financial and operational applications.

Key capabilities:

• Financial accounting and reporting
• Procurement and supplier management
• Project financial management
• Enterprise budgeting and planning
• Analytics and automated financial workflows

Key consideration: Particularly suitable for organisations seeking centralised financial oversight. However, buyers should evaluate detailed construction execution and scheduling requirements alongside Oracle’s broader construction technology portfolio.

4. Microsoft Dynamics 365

Best suited for: Mid-sized and large contractors seeking flexible enterprise management and Microsoft ecosystem integration.

Microsoft Dynamics 365 offers business applications covering finance, supply chain, operations and project-related processes.

Key capabilities:

• Financial management and reporting
• Procurement and inventory management
• Project operations
• Power BI analytics
• Integration with Microsoft 365 and Power Platform

Key consideration: Offers considerable flexibility, although construction-specific functionality may depend on partner applications and customisation.

5. IFS Cloud

Best suited for: Engineering, construction and asset-intensive businesses managing complex projects and equipment.

IFS Cloud combines enterprise resource planning, asset management and service management capabilities.

Key capabilities:

• Project lifecycle management
• Project costing and financial management
• Procurement and supply chain operations
• Equipment and asset management
• Resource planning and operational analytics

Key consideration: Worth evaluating for construction and engineering organisations where project delivery and asset-intensive operations are closely connected.

6. Acumatica Construction Edition

Best suited for: Small and mid-sized construction companies seeking integrated construction accounting and project management.

Acumatica Construction Edition is a cloud ERP solution with construction-oriented financial and project management capabilities.

Key capabilities:

• Construction accounting and job costing
• Project budgeting and cost tracking
• Purchase orders and subcontract management
• Change order management
• Project reporting and dashboards

Key consideration: Particularly relevant to growing contractors seeking integrated financial and construction management. However, buyers should confirm Philippine localisation, partner coverage and implementation support.

How do construction ERP systems in the Philippines compare?

The table below summarises the primary strength and typical target company of each of the six platforms covered in this guide.

How do you choose between construction ERP systems in the Philippines?

Before shortlisting construction ERP systems in the Philippines, companies should evaluate five requirements:

1. Construction-specific functionality: Does the platform support BoQ-based budgeting, subcontractor management, variations and project cost tracking?
2. Project cost visibility: Can management compare budgets, commitments, actual costs and project progress?
3. Integration capabilities: Can the ERP exchange information with Primavera P6, BIM tools, existing accounting platforms and other business systems?
4. Scalability: Can the system support multiple companies, large projects and geographically distributed operations?
5. Implementation and support: Does the vendor offer qualified implementation resources, coverage of Philippine regulatory requirements and long-term support arrangements?

In practice, a useful test is whether the vendor built the platform around project structures or adapted it from general business software. Our comparison of ProjectVIEW and generic ERP systems explains the difference in more detail.

Which construction ERP systems in the Philippines suit your company?

In short, there is no single construction ERP system that is best for every contractor in the Philippines.

For example, large EPC and infrastructure companies may prioritise detailed cost control, enterprise integration and complex project governance. By contrast, smaller contractors may place greater emphasis on construction accounting, usability and implementation cost.

The best construction ERP for 2027 is the platform that aligns most closely with the company’s project complexity, operational requirements and long-term growth strategy. For this reason, organisations should compare shortlisted solutions through product demonstrations, construction-specific use cases and a detailed evaluation of implementation requirements.

Frequently asked questions

What is a construction ERP system?

A construction ERP is enterprise software that connects estimating, budgeting, procurement, subcontractors, equipment, labour and accounting around the project. Unlike general accounting software, it tracks costs against the project structure, such as the Bill of Quantities and Work Breakdown Structure.

How is a construction ERP different from accounting software?

Accounting software records what the company has already spent. A construction ERP also tracks budgets, commitments, progress and forecasts per project, so management can see cost overruns before they reach the books.

How long does a construction ERP implementation take?

It depends on the scope, the number of modules and the integrations required. For example, a ProjectVIEW ERP implementation typically takes 5 to 7 months.

How much do construction ERP systems in the Philippines cost?

Costs vary by vendor, licensing model and implementation scope, so request quotes based on the same requirements from each shortlisted vendor. For ProjectVIEW ERP, pricing depends on the modules, the number of users and the deployment option. See ProjectVIEW ERP pricing or ask our team for a quote.

Does DANAOS have a presence in the Philippines?

Yes. DANAOS has a branch office in Bonifacio Global City (BGC), Taguig, Metro Manila, supporting clients in the Philippines and Southeast Asia.

See how ProjectVIEW ERP handles BoQ-based cost control on your own projects.

Book a Demo

Read more: 6 Best Construction ERP Systems in the Philippines for 2027

ProjectVIEW ERP v12 has officially launched and is now available to all DANAOS Projects clients. Version 12 builds ProjectVIEW AI into the way users manage, execute and optimise their processes, adds a new Production module for end-to-end project-based manufacturing, and introduces an MCP connector so that AI assistants such as Claude and ChatGPT can work directly with ProjectVIEW.

What is new in ProjectVIEW v12?

How does ProjectVIEW AI work in v12?

In v12, ProjectVIEW AI is integrated into users’ management processes, their execution and their optimisation. It works on homogenised, unified data: the operational data captured from all projects, together with the company’s internal data. Every answer and suggestion therefore comes from the same single source that the ERP itself uses.

What does the new Production module cover?

ProjectVIEW v12 adds a new Production module that covers project-based manufacturing end to end. Manufacturers that build to project, order or contract can now run production in the same system as their estimating, budgeting, procurement and cost control. Read more about materials and production management in ProjectVIEW ERP.

What can users do with the MCP connector?

MCP (Model Context Protocol) is an open standard for connecting AI assistants to business systems. With the new ProjectVIEW MCP connector, users can connect Claude or ChatGPT to ProjectVIEW and:

1. run headless operations, without opening ERP screens;
2. ask questions of their own data in plain language;
3. create the dashboards and KPIs they need;
4. build their own AI agents and assistants for further automation.

A new website to celebrate v12

To celebrate the launch of ProjectVIEW v12, danaos-projects.com has a new look: a new home page, redesigned menus and a simpler language selector, in English, Spanish, Japanese, Indonesian and Arabic.

Frequently asked questions

Who can use ProjectVIEW v12?

ProjectVIEW v12 is available now to all ProjectVIEW ERP clients.

Which AI assistants work with the ProjectVIEW MCP connector?

The connector is available for Claude and ChatGPT.

What is new for manufacturers in v12?

A new Production module that covers project-based manufacturing end to end.

How can I see ProjectVIEW v12?

Book a demo with our team and we will show you v12 on your own use case.

Book a Demo

Read more: ProjectVIEW ERP v12 Is Now Available to All Clients

From fragmented field conversations to structured enterprise intelligence: why voice-first AI could fundamentally change how construction sites, shipyards, mines and offshore operations capture and control reality.

The Future of ERP Is Not Another Screen. It Is an Operating System That Listens.

For decades, enterprise software has demanded that people adapt to computers.

Navigate menus. Complete forms. Select codes. Enter quantities. Submit transactions. Update reports.

Yet construction sites, shipyards, mines and offshore platforms do not operate like administrative offices.

Instead, they are dynamic sites spread over wide areas. There, engineers, supervisors, foremen and equipment operators make observations and decisions all day while they do physical work.

The challenge is not a lack of operational information. It is the inability to capture that information accurately, consistently and close to the moment it occurs.

So this is where voice-first AI and headless ERP operations introduce a different approach.

With DANAOS ProjectVIEW AI, field personnel can use natural speech to document activities and operational events in short voice recordings. As a result, they do not need to stop their normal workflows to navigate complex ERP interfaces.

Then AI transforms these fragmented observations into structured information. It also identifies their operational context and directs the relevant data into the correct ProjectVIEW ERP fields and workflows.

The objective is not simply to convert speech into text. It is to convert spoken observations into verified, actionable enterprise data.

1. What Is Headless ERP, and Why Does Voice Change Everything?

A headless operating approach separates the enterprise’s business logic and data processing from the user interface. The interface is only the layer that people use to interact with the system.

In conventional ERP interactions, users must navigate screens and forms to create a transaction.

In a headless, voice-first model, however, people can start those interactions in natural language. Meanwhile, the underlying ERP still enforces its established data structures, permissions, calculations and business rules.

Therefore, the distinction is fundamental:

• Traditional ERP: People translate reality into software fields.
• Voice-first ERP: People describe reality, while AI translates their observations into software-ready information.

ProjectVIEW ERP already provides the operational backbone for this approach. For example, it includes an integrated project data environment, role-based workflows and a standards-based API framework.

In addition, ProjectVIEW AI adds the intelligence layer. This layer interprets natural language and connects human observations with that structured environment.

However, this does not eliminate the ERP interface. Instead, it makes the interface optional for many routine reporting tasks. Conventional interfaces stay in place for supervision, verification, exception handling and approvals.

Headless operation is not the absence of control. It is the removal of unnecessary interaction complexity.

2. From Dispersed Voice Recordings to a Unified Daily Operational Record

How does a site engineer use voice reporting during the day?

For example, consider a site engineer who supervises several activities on a major infrastructure project. Throughout the working day, the engineer uses ProjectVIEW AI to capture brief observations whenever an operational event occurs.

08:10 — Workforce deployment

“Twelve carpenters and six steel fixers started work on the foundation structures in Zone B.”

10:45 — Equipment interruption

“Excavator EX-204 stopped because of a hydraulic problem. We have notified maintenance.”

13:20 — Materials and progress

“We placed thirty-five cubic metres of concrete in foundation section F3. The planned quantity for today was fifty cubic metres.”

15:40 — Operational constraints

“The subcontractor could not complete the remaining reinforcement because the material delivery arrived late.”

Each recording is an independent observation.

It may occur minutes or hours after the previous one. It may also concern a different activity, resource or subcontractor.

As a result, there is no need to construct a complete daily report while standing in the field.

Instead, ProjectVIEW AI assembles a structured operational picture from multiple fragmented recordings.

How does ProjectVIEW AI process the recordings?

The AI processing workflow follows six fundamental stages:

1. Voice capture: Authorized personnel create short, timestamped recordings through the field application.
2. Speech transcription: Speech recognition converts the recordings into searchable text, preserving the original context and available metadata.
3. Semantic interpretation: AI identifies activities, locations, quantities, dates, labor resources, machinery, materials, progress and reported disruptions.
4. Contextual association: AI then matches the extracted information with the relevant project, Bill of Quantities (BoQ), Work Breakdown Structure (WBS), Cost Codes and resource records.
5. Structured ERP population: The interpreted data populates the corresponding ProjectVIEW ERP records and transaction fields, subject to configured validation and authorization requirements.
6. Operational reconciliation: ProjectVIEW compares verified actual execution and resource consumption with the project’s approved budget, schedule and operational baseline.

Modern speech-to-text technologies already support capabilities such as batch transcription, language identification, timestamps and speaker differentiation. For example, see the documentation from Microsoft Azure Speech.

The critical differentiator, however, is not the transcription engine.

Instead, it is the enterprise business logic. This logic decides what the spoken information means, where it belongs and how it affects project execution.

3. Why ProjectVIEW’s BoQ–WBS–Cost Code Integration Is Critical

A generic AI transcription application can produce an excellent summary of a construction engineer’s observations.

But a summary is not a controlled ERP transaction.

For example, consider the statement:

“We placed thirty-five cubic metres of concrete in foundation F3.”

First, the enterprise must link this information to the project’s approved scope, schedule, resources and cost baseline. Only then does it become operationally useful.

As a result, ProjectVIEW ERP’s fundamental architecture becomes essential:

BoQ WBS Cost Codes

Bill of Quantities (BoQ) — What are we building?

Identifies the contractual or commercial work item, its measurement unit, associated quantities and budgeted resources.

Work Breakdown Structure (WBS) — When and where is the work scheduled?

Associates execution with planned activities, dependencies, durations and scheduled progress, including schedules managed through Oracle Primavera P6.

Cost Codes — How are resources and expenditures controlled?

Associates resource consumption and expenditure with the contractor’s internal cost structure.

ProjectVIEW ERP then connects these three dimensions across the enterprise.

When the system maps and validates field observations correctly, it can reconcile them with planned productivity and budgeted costs. This covers reported work quantities, labor allocation, equipment utilization and materials consumption.

As a result, it enables something substantially more valuable than automated reporting:

A continuous comparison of planned work, consumed resources, executed work and remaining work.

That is the foundation of ProjectVIEW’s Actual vs. Budgeted Cost Control methodology.

In short, AI makes it easier to capture operational observations. ProjectVIEW then makes those observations economically and operationally meaningful.

4. Voice-Driven ERP Across Construction, Shipyards, Mining and Offshore Operations

Voice-first field reporting is especially valuable where activities spread across large areas. It also helps where operational staff cannot easily use keyboards or lengthy digital forms.

Construction and Infrastructure

Site engineers and foremen can document quantities installed, labor deployment, equipment utilization, material shortages, productivity constraints and requests for inspection.

As a result, these observations support construction daily logs, progress measurement and project cost control.

Shipbuilding and Ship Repair

Supervisors can record fabrication progress, welding activities, equipment installation, repair findings, inspection observations and work interruptions. This applies across different vessels, workshops and dry docks.

The structured records then help associate yard execution with work packages, resources, project budgets and maintenance or production activities.

Mining and Quarrying

Field supervisors can document excavation and production activities, hauling operations, equipment downtime, maintenance events, workforce allocation and operational constraints.

In addition, these observations can complement machine telemetry and production measurements. They give more context for machinery utilization and operational cost analysis.

Marine and Offshore Construction

Personnel on vessels, offshore structures and marine construction sites can capture work progress and equipment status. They can also record weather-related interruptions, material movements and operational events.

When ProjectVIEW’s project-centric environment integrates this information, it can support progress tracking, resource control and timely escalation of operational deviations.

Across all these industries, therefore, the principle remains the same:

The closer information capture occurs to physical execution, the less the organization must rely on reconstructing the past.

5. From Voice Transcription to AI-Driven Cost Control

The real value emerges when voice-generated records become part of a connected operational data environment.

For example, suppose a field engineer reports that a concrete placement activity achieved only 70% of its planned daily quantity. However, equipment and labor resources stayed on the activity for the full shift.

Once verified and linked to the correct project activity, the observation then becomes an input to a much broader analysis.

ProjectVIEW ERP can compare reported and approved progress with resource transactions, budgeted productivity, schedule requirements and actual costs.

The AI layer can then help investigate the cause. For example, the deviation may reflect reduced productivity, equipment downtime, delivery delays, unforeseen site conditions or another operational constraint.

As a result, this information can help identify risks to project performance earlier.

It can also contribute to more complete supporting documentation for contractual variations, delay investigations and claims. However, voice recordings alone do not establish contractual entitlement or certified progress.

This is an important distinction.

AI should not invent operational certainty from an unverified observation.

For example, a team may need to check a recorded quantity against approved measurements. Similarly, equipment downtime may require confirmation through machinery records or telemetry. Finally, financially consequential transactions must follow authorized workflows.

In other words, the objective is not unrestricted automation.

It is faster data capture, intelligent classification and controlled execution.

This approach also follows the trustworthiness principles in the NIST AI Risk Management Framework.

6. Why Voice-First ERP Could Transform Enterprise Productivity

Traditional digital transformation has focused primarily on replacing paper documents with electronic forms.

But digital forms can still impose substantial administrative work on the people responsible for producing physical results.

Voice-first interactions, however, change that relationship.

First, engineers can spend more time supervising works. Second, foremen can document events as they occur. Third, project managers can receive operational information sooner. Meanwhile, administrative teams spend less time transcribing handwritten notes or consolidating disconnected reports.

Also, the potential benefits extend beyond convenience.

For example, more timely reporting can make daily records more complete and help teams detect deviations faster. It can also improve the inputs for cost forecasting and project performance management.

Crucially, voice can also capture knowledge that conventional forms often miss. Examples include the reasons behind a delay, the circumstances of an equipment failure, the sequence of site events or the conditions that affect productivity.

The people closest to execution often know these details, but the details never become part of the enterprise’s structured knowledge.

ProjectVIEW AI therefore provides a way to capture these observations and connect them to the relevant operational records.

Finally, teams should measure the effectiveness of this approach with practical indicators. These include reporting latency, completeness of daily logs, transcription accuracy, validated transaction rates, user adoption and the speed of cost-deviation detection.

7. The Evolution from ERP Data Entry to an Intelligent Operating Environment

The long-term transformation is larger than voice recognition.

In fact, voice is only one form of interaction within a broader AI-enabled operating environment.

Over time, the same enterprise can combine field speech with images, videos and documents. It can also add machinery telemetry, sensor measurements, drone observations and existing ERP transactions.

Each contributes a different dimension of operational evidence.

Through the ProjectVIEW ecosystem, AI can interpret this information against the same project structures and business rules. As a result, the data does not stay isolated in disconnected applications.

This is the architectural direction behind ProjectVIEW OS:

ProjectVIEW ERP — The Process and Data Layer

The system of record that manages structured data, transactions, resources, budgets, permissions and approvals.

ProjectVIEW AI — The Intelligence and Automation Layer

The AI environment that interprets unstructured information, provides contextual reasoning and supports purpose-specific automation.

Together, they establish the foundation for a more intelligent, project-centric operating environment.

Read more: ProjectVIEW OS — The Operating System for the BUILD World.

8. The Most Important Question: Can Your ERP Understand Reality as It Happens?

In construction and other capital-intensive industries, competitive advantage depends more and more on speed. In particular, it depends on how quickly companies see the gap between their plans and actual execution.

Enterprise software should not force employees to interrupt productive work merely to communicate what is happening.

Instead, it should be intelligent enough to interpret natural human observations and link them to the correct business context. Then it should transform them into controlled operational information.

That is the opportunity behind voice-first, headless ERP operations.

People speak. AI interprets. ProjectVIEW ERP structures, validates and controls.

And the system can continuously connect verified field information to project scope, time, resources and cost. As a result, the enterprise moves closer to an essential objective:

Capturing operational reality while there is still time to act on it.

Therefore, the number of screens users can access will not define the next generation of construction ERP.

Instead, the test is how well the operating system understands the work in progress. Just as important is how reliably it connects that reality to business decisions.

The power of voice is not simply making ERP easier to use. It is making project execution easier to understand, control and optimize.

Read more: The Power of Voice: How ProjectVIEW AI Transforms Construction ERP Through Headless Operations

The future of Artificial Intelligence in capital engineering projects will not be determined by the sophistication of AI models alone. It will be determined by the reliability, connectivity, and operational context of the data those models consume.

Today, construction companies, mining operators, and shipyards are investing in Artificial Intelligence (AI), Industrial Internet of Things (IIoT), digital twins, predictive analytics, and autonomous AI agents.

Yet one fundamental question remains largely unanswered:

How can AI make reliable operational decisions when disconnected applications, spreadsheets, equipment systems, and departmental databases fragment the information it depends on?

An AI agent may be capable of analyzing millions of records. However, that capability becomes commercially meaningful only when it can establish what those records represent, how they relate to one another, and whether they reflect the current operational reality.

In addition, this challenge is particularly significant in capital-intensive engineering industries, where project execution involves thousands of interdependent activities, substantial equipment investments, complex supply chains, strict contractual obligations, and continuously changing operational conditions.

So the answer is not simply to introduce more AI.

Instead, it is to establish an industry-specific, enterprise-wide operating ecosystem that connects operational reality with engineering, time, cost, resources, contracts, and financial performance.

This is the architectural principle behind DANAOS ProjectVIEW ERP and the evolution toward ProjectVIEW AI.

1. Three Industries, Three Operational Realities — One Fundamental Challenge

Construction management, mining management, and shipyard management share important characteristics.

For example, all three require extensive capital investment, complex resource coordination, engineering expertise, machinery utilization, procurement, workforce management, cost control, and regulatory compliance.

However, their operating environments are fundamentally different.

As a result, an enterprise-wide AI ecosystem must recognize these differences rather than impose generic business logic on industries with distinct operational requirements.

Construction: Managing Progress, Productivity, and Contractual Risk

Construction predominantly revolves around projects with defined scopes, contractual milestones, budgets, and completion dates.

Whether delivering a high-rise building, transportation infrastructure, an industrial plant, or an offshore facility, contractors must coordinate:

• Engineering designs, drawings, BIM models, and revisions.
• Bills of Quantities (BoQ), cost estimates, and project budgets.
• Work Breakdown Structures (WBS) and construction schedules.
• Materials procurement, logistics, and inventory.
• Labor productivity, equipment utilization, and subcontractor performance.
• Progress measurements, variations, claims, and certifications.
• Cash flow, earned value, and project profitability.

In practice, the fundamental management challenge is not simply knowing how much money the project has spent.

Instead, it is understanding how much physical work the team has actually executed and what resources it consumed. It also means checking whether the achieved productivity justifies the expenditure and how deviations affect the remaining project budget and schedule.

Consequently, an AI system that only reads financial transactions cannot reliably answer these questions.

Instead, it needs a relationship between engineering quantities, planned activities, resources, and actual site execution.

Mining: Managing Continuous Production, Equipment Availability, and Resource Economics

Mining, by contrast, differs substantially from conventional construction.

Although mine development and expansion are capital projects, active mining is generally a continuous, asset-intensive production operation.

Mining management depends on the coordination of:

• Geological models, mine plans, and production sequences.
• Drilling, blasting, excavation, loading, and hauling.
• Haul-truck fleets, excavators, crushers, and processing equipment.
• Equipment availability, utilization, and maintenance.
• Fuel consumption, energy requirements, and spare parts.
• Ore grades, recovery rates, production volumes, and material movements.
• Environmental monitoring, permits, safety, and regulatory obligations.
• Production cost per tonne and operational profitability.

A mine’s economic performance depends closely on the productivity of its equipment, the characteristics of the material it extracts, and the efficiency of the entire production chain.

A mining AI agent must therefore understand much more than purchase orders and accounting records.

For example, a rising cost per tonne may result from deteriorating equipment availability, longer haul distances, higher fuel consumption, lower ore grades, or reduced processing efficiency.

Without connecting production measurements, fleet telemetry, maintenance records, resource costs, and operational plans, AI cannot reliably distinguish the causes of declining profitability.

Shipyards: Managing Engineering Complexity, Production Capacity, and Vessel Turnaround

Shipbuilding and ship repair, in turn, introduce another operating model.

Shipyards combine project management with industrial fabrication, engineering change management, production scheduling, specialized subcontracting, and intensive asset utilization.

For instance, a shipyard may simultaneously manage newbuild vessels, ship repairs, dry-docking operations, offshore structures, and steel fabrication projects.

Its management requirements include:

• Vessel specifications, engineering packages, and production drawings.
• Work packages, production stages, and fabrication sequences.
• Steel cutting, welding, assembly, outfitting, and commissioning.
• Dry-dock occupancy, berth availability, and crane utilization.
• Materials traceability and warehouse management.
• Skilled workforce allocation and subcontractor coordination.
• Classification society requirements, inspections, and quality records.
• Change orders, additional works, and customer certifications.
• Vessel delivery milestones, turnaround time, and project profitability.

Unlike a conventional construction site, a shipyard often manages multiple projects competing for the same production facilities, skilled workers, docks, and heavy equipment.

In ship repair, moreover, unexpected conditions discovered after inspection can substantially alter the original scope.

An intelligent shipyard operating ecosystem must therefore connect the vessel’s technical condition, approved work scope, production capacity, material availability, schedule, and commercial consequences.

Consider an AI agent that knows the vessel’s planned departure date but cannot interrogate the actual progress of repairs, critical spare-parts availability, or dry-dock constraints. Such an agent is not delivering meaningful operational intelligence.

2. Why Generic AI Models Cannot Understand Engineering Operations by Themselves

Large Language Models (LLMs) are exceptionally capable of interpreting language, summarizing documents, retrieving information, and supporting analytical workflows.

However, language intelligence is not equivalent to engineering or operational intelligence.

Consider three questions:

• Construction: Why has the reinforced-concrete package exceeded its budget despite reporting 80% completion?
• Mining: Why has the cost per tonne increased despite maintaining the planned production volume?
• Shipyard: Can Vessel A leave dry dock three days earlier without affecting the critical path of Vessel B?

Searching documents alone cannot reliably answer these questions.

Instead, they require structured relationships between operational events, engineering scope, planned and actual quantities, time, resources, financial commitments, and physical constraints.

A generic AI model may generate a plausible explanation.

But plausibility is not proof.

Therefore, for enterprise-grade engineering operations, AI must distinguish between:

• Planned versus actual progress.
• Committed versus incurred costs.
• Available versus allocated resources.
• Approved versus proposed engineering changes.
• Recorded versus verified production quantities.
• Historical trends versus current operational conditions.

It must also identify the source, timestamp, and approval status of the information used.

This is why AI readiness is fundamentally an enterprise data architecture challenge — not merely an AI software procurement decision.

3. The Data Mesh: Weaving Disconnected Operational Information into Business Intelligence

The term data mesh describes an architectural approach that structures data around business domains. Each domain has clearly defined ownership, quality standards, and interoperable data products.

For engineering-intensive enterprises, the practical objective is to establish a trusted and interconnected data fabric spanning the entire organization.

The distinction matters.

For example, a data lake can store enormous quantities of information without necessarily explaining the relationships between them.

Similarly, a data warehouse can consolidate historical information without always providing the operational context needed to execute business decisions.

By contrast, a data mesh, supported by common business definitions and integration standards, can make domain information discoverable, governed, and reusable.

However, a data mesh does not automatically establish a single operational truth.

For that, an enterprise needs a consistent business model connecting the various data domains.

The essential operational data domains

An AI-ready capital engineering enterprise must connect information from:

1. Engineering and planning: BoQ, WBS, BIM, CAD, geological models, production plans, engineering revisions, and technical specifications.
2. Execution and production: Daily progress, installed quantities, fabricated components, extracted tonnage, inspections, production logs, and completion records.
3. Resources and assets: Labor, machinery, vessels, equipment, fuel, maintenance, availability, and utilization.
4. Commercial operations: Estimation, tendering, procurement, subcontracting, contracts, variations, certifications, and claims.
5. Financial management: Budgets, cost codes, commitments, actual costs, accounting, cash flow, and profitability.
6. External operational intelligence: Equipment telematics, IoT sensors, drones, GIS, environmental monitoring, third-party applications, and relevant market data.

These domains must not remain isolated.

Indeed, the real value emerges when the enterprise can interpret a production event recorded in one domain in the context of all the others.

For example, a machinery breakdown should not exist only as a maintenance ticket.

The enterprise should also be able to determine which activities the breakdown affects and what production capacity it loses. In addition, it should see whether substitute equipment is available, what the financial consequences are, and which corrective actions require approval.

This is the difference between collecting data and operationalizing data.

4. ProjectVIEW ERP: The Business Logic That Connects Time, Cost, and Operational Reality

DANAOS ProjectVIEW ERP focuses specifically on project-centric and capital-intensive engineering businesses.

Its distinguishing characteristic is not simply the integration of ERP modules.

Instead, it is the business logic connecting engineering scope, execution schedules, enterprise cost structures, and actual resource consumption.

At its core is the relationship:

BoQ WBS Company Cost Control Accounts

Each dimension answers a different business question.

BoQ — What must be delivered, and at what estimated cost?

The Bill of Quantities provides the contractual or production scope, measurable quantities, resource requirements, and cost-estimation baseline.

WBS — When and in what sequence must the work be executed?

The Work Breakdown Structure connects the scope to scheduled activities, milestones, dependencies, and planned progress.

Company Cost Control Accounts — Where are resources and costs allocated, monitored, and consolidated?

The enterprise cost structure provides consistent financial and operational classifications across projects, departments, subsidiaries, and business units.

By relating these dimensions, ProjectVIEW ERP creates a contextual operational model rather than merely a collection of disconnected financial records.

Why this matters for AI

For example, consider a construction activity requiring 1,000 cubic meters of concrete.

• The BoQ defines the planned quantity and associated resources.
• The WBS establishes the execution period and dependencies.
• Cost control accounts identify how the company classifies and monitors expenditures.

Finally, daily site transactions record the actual installed quantity, labor hours, equipment usage, materials consumed, and subcontractor contributions.

Developers can then design an authorized AI agent to interrogate this connected information and ask:

• Is productivity below the budgeted benchmark?
• Is material consumption disproportionate to executed quantities?
• Are labor costs increasing because of overtime or reduced output?
• Will current performance affect the forecast cost at completion?
• Which approved corrective actions are available?

The difference is fundamental.

The AI is no longer interpreting isolated numbers. Instead, it is reasoning over a structured representation of engineering and business reality.

This is the foundation for more reliable cost forecasting, anomaly detection, and operational decision support.

5. From Construction Sites, Mines, and Shipyards to a Connected Enterprise Data Fabric

ProjectVIEW ERP can act as the central operational coordination layer while specialized applications continue performing their original functions.

The objective is not to replace every engineering or industrial application.

Instead, it is to connect their relevant outputs to a consistent enterprise business model.

Engineering and scheduling integration

ProjectVIEW ERP provides native integration with Oracle Primavera P6, supporting the relationship between project schedules and operational cost control.

Its support for Industry Foundation Classes (IFC) also enables integration of information originating from compatible BIM applications.

As a result, these integrations help connect engineering and planning information with operational and commercial records.

Site and yard data capture

Daily transactions provide the operational evidence required to compare planned activities with actual execution.

This includes work progress, workforce utilization, machinery transactions, material movements, and subcontractor performance.

The closer data capture occurs to the point of execution, the more useful it becomes for operational decision-making.

Procurement, inventory, and financial systems

ProjectVIEW integrates procurement, warehouse management, subcontracting, budgeting, and cost control.

Its API capabilities also support integration with third-party enterprise systems, including SAP and Oracle, subject to implementation scope.

This allows organizations to preserve existing enterprise investments while establishing stronger project-specific operational control.

Equipment, vessels, and industrial data

In addition, machinery telematics, IoT, fleet management, and industrial monitoring systems can contribute valuable operational information.

In marine and offshore environments, integration with specialized maritime applications can extend the data ecosystem to vessel operations, technical management, and fleet performance.

Through the wider DANAOS technology ecosystem, DANAOS can position ProjectVIEW alongside specialized maritime software expertise from DANAOS Management Consultants.

However, each implementation must configure and validate the specific telemetry, vessel, GIS, or industrial-system interfaces.

The strategic objective is a governed, interoperable ecosystem in which relevant operational information becomes accessible without losing its original meaning, ownership, or traceability.

6. ProjectVIEW AI: From Business Intelligence to Intelligent Business Orchestration

Traditional Business Intelligence primarily explains what happened.

Predictive analytics then estimates what may happen.

AI agents introduce a further possibility: identifying conditions, investigating their causes, recommending actions, and — where explicitly authorized — initiating controlled business workflows.

This is the direction of ProjectVIEW AI.

The objective is to make ProjectVIEW’s integrated operational data accessible to purpose-specific AI agents, whether developed within the ProjectVIEW ecosystem or connected through governed integration interfaces.

Such agents could operate across several intelligence layers.

Descriptive intelligence: What is happening?

AI assistants can retrieve and summarize authorized operational information, highlight deviations, and explain performance indicators.

Diagnostic intelligence: Why is it happening?

Agents can examine relationships between resource consumption, progress, production, procurement, equipment utilization, and cost.

Predictive intelligence: What is likely to happen?

Analytical models can use validated historical and current information to forecast cost overruns, production delays, resource shortages, or equipment-related disruptions.

Prescriptive intelligence: What should we do?

Agents can evaluate alternatives, quantify potential consequences, and recommend corrective actions.

Controlled agentic execution: Can the system initiate action?

With appropriate permissions, validation, and approval workflows, AI agents can potentially prepare procurement requests, escalate exceptions, recommend resource reallocations, or initiate other defined business processes.

Importantly, AI recommendations and automated actions must remain subject to operational controls, role-based permissions, and human authorization wherever commercial, contractual, safety, or regulatory consequences are at stake.

This is not unrestricted autonomy.

Instead, it is orchestration that operates under clear governance.

7. Three Industry-Specific AI Agent Scenarios

Scenario A: Construction Cost Control Agent

A construction contractor is executing several infrastructure projects.

However, daily records indicate that excavation productivity has fallen below the budgeted benchmark.

The contractor could configure a cost-control agent to interrogate:

• Executed excavation quantities.
• Planned and actual labor hours.
• Excavator and truck utilization.
• Fuel consumption.
• Haul distances and equipment availability.
• WBS progress and remaining quantities.
• Current cost commitments and budget forecasts.

The agent then identifies a potential relationship between declining productivity, equipment downtime, and increased haulage requirements.

Finally, it produces an evidence-backed exception report, estimates the potential impact on the cost at completion, and recommends corrective measures for the project manager’s approval.

Scenario B: Mining Production and Fleet Intelligence Agent

A mining operation records stable daily output but increasing production costs.

An AI agent connected to validated mine-production, fleet, maintenance, and cost data could investigate whether the increase stems from:

• Reduced truck availability.
• Higher fuel consumption per tonne.
• Increasing haulage distances.
• Changes in material characteristics.
• Maintenance-related production losses.
• Inefficient equipment deployment.

Instead of reporting only the higher cost, the agent can investigate the operational drivers behind it.

It can then recommend alternative fleet allocations or maintenance windows for engineering review.

Scenario C: Shipyard Production and Dry-Dock Optimization Agent

A shipyard manages multiple vessels undergoing scheduled maintenance and repair.

During inspection, the yard identifies additional steel replacement work on one vessel.

The yard could then configure a shipyard AI agent to correlate:

• The approved and revised repair scope.
• Required materials and their availability.
• Welding and fabrication capacity.
• Workforce and subcontractor availability.
• Dock occupancy and production schedules.
• Inspection and certification requirements.
• Contractual variation procedures.
• The potential effect on other vessels.

As a result, the agent could identify scheduling conflicts, estimate additional resource requirements, and prepare a proposed recovery plan.

Commercial changes would still require the relevant approvals.

These are illustrative target workflows for an AI-enabled enterprise architecture, not claims that every described agent is already available as a standard ProjectVIEW feature.

8. Reliable Data Is More Important Than More Data

Industrial AI systems face an important limitation: operational records are not automatically accurate simply because they are digital.

• A sensor can malfunction.
• A daily progress report can be incomplete.
• A subcontractor may report quantities that no one has certified yet.
• A procurement transaction may represent a commitment rather than an actual incurred cost.
• A later revision may have superseded an engineering drawing.
• A financial record may be correct for accounting purposes but insufficient to explain physical productivity.

Therefore, for AI to become trustworthy, information needs several essential characteristics.

• Traceability: Every critical value should link to its original transaction, document, equipment record, or approved source.
• Context: Each record must reference the relevant project, work package, activity, cost account, asset, and reporting period.
• Timeliness: AI should distinguish live information from delayed, historical, or provisional records.
• Consistency: Common resource classifications, measurement units, cost structures, and master data are essential.
• Governance: Users and AI agents should access only information and actions authorized for their roles.
• Validation: Defined business processes must reconcile operational quantities, costs, and approvals.
• Explainability: AI-generated conclusions should identify supporting evidence, assumptions, uncertainty, and relevant exceptions.

These requirements are particularly important in construction, mining, and shipyards because decisions can have substantial financial, contractual, environmental, and safety consequences.

The fundamental principle is straightforward:

AI must not simply retrieve enterprise data. Instead, it must be able to establish whether that data is suitable for the decision at hand.

9. Why ERP Is the Operational Foundation — Not the Entire AI Ecosystem

It would be misleading to suggest that ERP alone can replace geological modeling, industrial control systems, BIM authoring, scheduling engines, or specialized maritime applications.

After all, these systems have distinct responsibilities.

• A mine-planning application understands geological and extraction constraints.
• A BIM application represents engineering geometry and asset information.
• Primavera P6 manages detailed project scheduling.
• A vessel-management system maintains specialized maritime operational records.
• Industrial telemetry systems measure physical equipment behavior.

By contrast, the role of an industry-specific ERP is different.

It provides the enterprise business context that connects these specialized systems to resources, contracts, costs, workflows, and financial outcomes.

This distinction is crucial.

Without specialized systems, the enterprise loses technical depth.

Similarly, without integrated enterprise business logic, the organization struggles to convert technical information into coordinated operational and commercial decisions.

Finally, without appropriate AI governance, users and agents can misinterpret or misuse even integrated information.

The intelligent enterprise therefore requires three complementary foundations:

1. Specialized operational systems that capture and process engineering and industrial information.
2. An integrated enterprise operating platform that connects processes, resources, time, cost, and commercial accountability.
3. A governed AI ecosystem that can interrogate this information and support decisions or controlled actions.

DANAOS positions ProjectVIEW ERP as the second foundation — and as the operational context layer supporting the third.

10. The Roadmap: From Fragmented Digitalization to AI-Orchestrated Operations

For enterprise contractors, mining companies, and shipyards, leaders should approach AI transformation as a progressive operational program.

Stage 1 — Establish reliable enterprise master data

First, standardize project structures, cost accounts, resources, equipment registers, measurement units, and organizational responsibilities.

Stage 2 — Integrate core operational workflows

Connect estimating, planning, procurement, production, workforce, equipment, contracts, and financial control.

Stage 3 — Connect specialized engineering and industrial systems

Integrate relevant scheduling, BIM, mine-planning, vessel-management, GIS, IoT, and telematics information.

Stage 4 — Validate operational performance

Establish systematic reconciliation between planned and actual quantities, progress, costs, resource utilization, and approved changes.

Stage 5 — Introduce purpose-specific AI assistants

Begin with high-value, lower-risk use cases such as enterprise knowledge retrieval, exception reporting, cost analysis, and operational summaries.

Stage 6 — Deploy predictive and prescriptive intelligence

Extend into forecasting, anomaly detection, maintenance optimization, production analysis, and scenario evaluation.

Stage 7 — Enable governed AI orchestration

Finally, allow authorized AI agents to initiate selected workflows, supported by validation, permissions, approval mechanisms, audit trails, and human oversight.

The objective is not to automate everything immediately.

Instead, it is to build an enterprise capable of introducing increasingly sophisticated AI without compromising operational control.

11. The Competitive Advantage Will Belong to Enterprises That Control Their Data

However, the organizations that benefit most will not necessarily be those deploying the greatest number of AI applications.

They will be those capable of answering essential business questions accurately and consistently:

• What work has the team actually completed?
• What resources did that work consume?
• How does performance compare with the approved baseline?
• What is driving the deviation?
• What will happen if the current trend continues?
• Which corrective actions are technically feasible and commercially justified?
• Who has the authority to approve and execute those actions?

These questions require more than dashboards, isolated data repositories, or conversational AI interfaces.

Instead, they require an integrated operational model of the enterprise.

This is where the distinction between generic digitalization and genuine operational transformation becomes apparent.

Digitalization records business activities. Integration connects them. AI can interpret their relationships. Governed AI orchestration can help the enterprise act on that intelligence.

At DANAOS Projects, our vision is to position ProjectVIEW ERP as the central command center for construction, mining, marine engineering, offshore operations, shipbuilding, and ship repair.

An enterprise-wide platform that weaves together the operational data fabric, connects specialized engineering and industrial systems, and establishes the business context required by ProjectVIEW AI and other authorized AI agents.

Our objective is not simply to help enterprises adopt Artificial Intelligence.

Instead, it is to help them build the operational foundation that makes Artificial Intelligence reliable, actionable, and commercially valuable.

Because in capital engineering projects, the ultimate measure of intelligence is not how much data a system can process.

It is how effectively that intelligence protects margins, improves productivity, controls risk, and supports profitable execution.

Read more: AI in Construction, Mining & Shipyards: Why Industry-Specific ERP Is the Foundation of Intelligent Operations

Construction drones are becoming powerful data-collection instruments. But drone data alone does not control a project.

The real value begins when the project team connects images, point clouds, quantities, inspection findings and geospatial data with the project’s Bill of Quantities (BoQ), Work Breakdown Structure (WBS), schedule, cost codes, resources, machinery, vessels, contracts and actual expenditure.

That is the difference between reality capture and reality-based project control.

For example, a recent analysis of the Japan construction drone market identifies several trends accelerating drone adoption. These include automated site mapping, surveying, infrastructure inspection, AI-powered image processing, real-time progress tracking, BIM interoperability and predictive maintenance.

Japan is particularly relevant. The Ministry of Land, Infrastructure, Transport and Tourism’s i-Construction program has promoted UAV surveying and 3D data throughout surveying, construction and inspection workflows. In addition, Japanese guidance specifically recognizes drone photogrammetry for high-density 3D surveying. It also recognizes the use of 3D data to calculate construction quantities and support ICT-enabled construction.

However, the next step is bigger:

Connect what the drone sees with what the enterprise knows.

What Is the Missing Link Between Construction Drones and ERP?

A drone can tell you what exists at a particular location and point in time.

By contrast, an ERP should tell you what that observation means to the project.

Modern UAV workflows can generate high-resolution imagery, orthomosaics, point clouds, terrain models, volumetric measurements, thermal imagery and increasingly AI-classified observations.

Academic research has already demonstrated the value of combining UAV photogrammetry with BIM. For example, a systematic review of UAV technologies in construction found progress monitoring to be one of the dominant applications. These applications commonly use drone imagery to create an as-built 3D model and then compare it with the planned model.

More recent research goes further. For instance, a 2026 study integrating UAV photogrammetry, BIM and automated point-cloud comparison demonstrated quantitative assessment of completed, ongoing and pending works while identifying schedule deviations.

But there is still a fundamental enterprise question:

Progress against what?

• A 3D model can identify that an object exists.
• A schedule can indicate that an activity should be complete.

However, neither, by itself, explains whether the project has earned the corresponding quantities or whether the resources consumed were reasonable. Nor does either show whether to certify subcontractors or whether actual cost matches physical progress.

This is where ProjectVIEW ERP changes the equation.

Drone Data Should Ultimately Become a Project Transaction

ProjectVIEW ERP centers on the relationship:

BoQ WBS Cost Codes

The BoQ represents contractual and measurable scope.

The WBS represents activities, sequence and time.

Cost Codes represent how the enterprise categorizes and controls expenditure.

The objective of integrating drone-derived data should therefore not be to create another dashboard.

Instead, it should be to transform observed reality into structured evidence supporting ERP transactions.

For example, a practical data chain can look like this:

1. Capture reality: UAVs, fixed cameras, mobile devices, LiDAR, GNSS, machinery telematics, IoT sensors and, where relevant, ROV/AUV systems collect field evidence.
2. Interpret reality: Photogrammetry, computer vision and AI identify quantities, assets, conditions, objects, defects, progress or anomalies.
3. Contextualize reality: BIM, GIS and project coding locate the observation against the relevant asset, area, BoQ item or WBS activity.
4. Reconcile reality: ProjectVIEW ERP compares observed progress with scheduled progress, budgeted resources, actual labor, machinery, materials, subcontractors and cost.
5. Act on reality: ProjectVIEW workflows trigger review, inspection, approval, corrective action, maintenance, certification, forecasting or management alerts.

In other words, the drone becomes an additional field observer. ProjectVIEW becomes the operational system of record. AI becomes the interpretation and reasoning layer.

Can Drone Data Complete the Construction Daily Log?

It can substantially strengthen it—but it should supplement, not blindly replace, controlled field reporting.

A construction daily log traditionally depends on information entered by supervisors, engineers, timekeepers, plant managers, subcontractors and other site personnel.

ProjectVIEW already structures site and yard information around progress, labor productivity, materials consumption, machinery utilization, inspections, work orders and other operational records. DANAOS specifically describes digitized contractor daily logs as a means of improving real-time project visibility and coordination.

Now imagine supplementing that human record with machine-generated evidence.

• A UAV-derived terrain model can cross-check a progress entry stating that excavation reached a particular quantity.
• Similarly, teams can compare a stockpile quantity with warehouse and materials records.
• Engineers can also compare concrete, steel, piping or structural progress against imagery, BIM objects and corresponding BoQ items.
• An inspection request can include georeferenced imagery captured shortly before submission.

AI can identify discrepancies between yesterday’s and today’s images, highlight areas requiring human verification and prepare a structured draft of the daily construction report.

The result is not “AI replacing the site engineer.”

Instead, it is a better evidence chain.

Why Heavy Machinery Utilization Is Critical in Construction and Mining

In construction and mining, production is inseparable from machinery.

Excavators, loaders, dump trucks, dozers, graders, cranes, drilling rigs and other heavy assets are not simply equipment on an asset register. Instead, they are productive resources whose time, availability, utilization, fuel and maintenance directly influence unit cost and production rates.

For example, recent research on earthmoving fleet monitoring shows that GNSS and telematics can classify working versus idle states, analyze equipment cycles and support real-time productivity assessment.

Caterpillar similarly combines telematics information such as utilization, fuel consumption and work-versus-idle time with inspections and maintenance history to understand equipment performance and health.

Komatsu’s Smart Construction ecosystem demonstrates the same broader direction: it combines design information, machine-generated as-built data and drone aerial mapping to visualize progress and quantities.

ProjectVIEW ERP, in turn, takes this operational information into the project-management and cost-control environment. Its Machinery Management capabilities include working and idle hourly cost, machinery scheduling and allocation, logistics and mobilization, preventive and corrective maintenance, daily machinery utilization linked to BoQ structures and machinery telematics.

This is particularly important in mining and quarrying. There, the relationship between excavator productivity, truck cycles, loading efficiency, haul routes, fuel consumption, equipment availability and production tonnage can determine the economics of the entire operation.

Knowing an excavator’s location is useful.

However, knowing whether it was productive is better.

But knowing what quantity it produced, for which activity, at what cost and against which budget is enterprise control.

From Machinery Fleet Management to Vessel Fleet Management

The same principle also extends offshore.

Marine construction, offshore energy and shipyard operations add another class of capital-intensive resources: vessels.

Tugs, barges, dredgers, crane vessels, crew boats, supply vessels, jack-ups, installation vessels and other floating assets participate directly in project execution.

Their mobilization, operating hours, fuel, availability, weather exposure, maintenance, inspections and downtime can materially affect project cost and schedule.

DANAOS ProjectVIEW ERP addresses marine and offshore operations across yards, sites and vessels, including vessel mobilization scheduling, fleet and equipment management, maintenance logs and integration with project logistics and cost centers.

This matters because fleet activity should not exist outside the project’s daily operational record.

After all, a vessel supporting a WBS activity offshore is consuming time and money just as an excavator supporting an earthworks activity is consuming time and money on land.

So both should ultimately contribute to the same operational truth.

Can Drones Be Used for Marine and Offshore Inspection?

Yes—but with an important technical distinction.

Inspectors increasingly use aerial and confined-space drones for visual inspection of ships and offshore structures. DNV has used drone-assisted surveys for ballast and cargo tanks, cargo holds, jack-up legs and structural components of maritime and offshore installations.

DNV research is also combining drones, LiDAR and AI for remote ship-hull inspection, including identifying potential cracks and corrosion for closer human assessment.

This can reduce the need for scaffolding, staging and hazardous human access. DNV has also demonstrated drone inspection on offshore floating assets, including an FPSO tank where an algorithm processed captured video to detect potential structural cracking.

But aerial drones do not replace subsea inspection.

Below the waterline, Remotely Operated Vehicles (ROVs), Autonomous Underwater Vehicles (AUVs), sonar and underwater inspection systems become part of the same broader reality-capture architecture. Lloyd’s Register explicitly recognizes UAVs, drones, ROVs, robotic systems and other remote inspection techniques for appropriate survey applications.

The enterprise opportunity, therefore, is to bring evidence from above water, below water, onboard and ashore into one governed operational environment.

Why ProjectVIEW ERP + AI Changes the Value of Reality Capture

AI becomes genuinely valuable when it has context.

For example, an AI model looking at a drone image may identify a machine, concrete element, stockpile, pipe, corrosion area or incomplete structure.

ProjectVIEW then provides the missing business context:

Which project, BoQ, WBS activity and location? What subcontractor, machine or vessel? Which inspection, budget and cost account? And what planned completion date?

As a result, that context allows ProjectVIEW AI to move beyond image classification toward operational reasoning.

DANAOS defines ProjectVIEW OS as ProjectVIEW ERP—the process and data layer—combined with ProjectVIEW AI—the intelligence and autonomy layer, with BoQ–WBS–Cost Code connectivity providing a structured project foundation for AI analysis.

That architecture creates the possibility of AI-assisted deviation detection, inspection prioritization, productivity analysis, maintenance alerts, progress validation, forecasting and automated reporting. Moreover, all of these rest on structured project reality rather than isolated images or generic prompts.

The Future Is Not Drone Management. It Is Integrated Reality Management.

Today, construction technology is accumulating sensors everywhere.

• Drones see the project from above.
• Site personnel report what happened on the ground.
• Machinery telematics records how crews operated equipment.
• BIM describes what should exist.
• Primavera defines when activities should happen.
• ROVs and inspection robots can document difficult or submerged environments.
• Vessels generate operational, maintenance and mobilization records.

The mistake, however, is allowing every technology to create another isolated data silo.

Real digital construction begins when these data streams converge around the same project structure.

For DANAOS Projects, that structure is ProjectVIEW ERP.

The long-term objective is straightforward:

Site + Yard + Machinery + Vessel + Drone + BIM + Schedule + AI → ONE operational truth.

Because collecting more data does not automatically create control.

Connecting reality to scope, time, resources and cost does.

Frequently Asked Questions

How can construction drone data integrate with an ERP system?

Teams can process drone imagery, point clouds, measurements and inspection data through photogrammetry, BIM, GIS or AI platforms. They can then exchange the results with an ERP through APIs, structured files or integration services. In ProjectVIEW ERP, the business objective is to associate validated information with the relevant project, BoQ, WBS, Cost Code, resource, asset, inspection or operational transaction.

Can drones automatically measure construction progress?

UAV photogrammetry and AI can automate significant portions of progress measurement, particularly where teams can reliably observe quantities or physical geometry. For example, research demonstrates the comparison of drone-generated as-built models with planned BIM models. Still, human validation remains important, particularly for contractual certification, concealed works and activities that remote capture cannot reliably observe.

Why should drone data be connected with machinery and labor data?

Physical progress alone does not reveal productivity or cost performance. Therefore, a contractor must understand the resources consumed to achieve that progress. Connecting observed quantities with labor hours, machinery hours, materials and subcontractor transactions allows management to assess whether production aligns economically with the project baseline.

How can AI improve drone-based construction monitoring?

AI can classify imagery, identify objects and anomalies, compare changes between capture periods, prioritize inspections and help convert unstructured visual evidence into structured operational information. When combined with an ERP, AI can additionally analyze those observations within project cost, schedule, procurement, resource and contractual context.

How does this apply to marine and offshore construction?

The same model applies across yards, vessels and offshore assets. Aerial drones can inspect accessible structures and hard-to-reach areas, while ROVs and other remote inspection technologies extend data capture below the waterline. When the organization connects inspection, vessel, equipment and project records, it gains a more complete operations and maintenance history.

References and Further Reading

Japan construction drone market analysis: Optiusd Group, Japan Construction Drone Market Regional Size, Trends and Forecast to 2033. Read the LinkedIn market article

Japan i-Construction and UAV surveying: Ministry of Land, Infrastructure, Transport and Tourism / Geospatial Information Authority of Japan. MLIT i-Construction guidance GSI 3D mapping and UAV guidance

Academic research: Unmanned Aerial Vehicles Integration with Digital Technologies toward Construction 4.0, Sustainability. Read the systematic literature review

UAV + BIM progress monitoring: Integrated Information System for Periodic Construction Progress Monitoring: Utilizing UAV, Photogrammetry, and BIM, Civil Engineering Sciences, 2026. Read the research article

Heavy-equipment utilization: Caterpillar Fleet Management and Komatsu Smart Construction. Caterpillar equipment utilization Komatsu Smart Construction Dashboard

Marine and offshore drone inspections: DNV remote and drone-assisted ship surveys. DNV drone surveys

DANAOS ProjectVIEW ERP: ProjectVIEW ERP and ProjectVIEW AI Operating System

Marine and offshore operations: ProjectVIEW ERP for marine construction and upstream operations

Related Resources

Shipyard Management Software & Shipbuilding ERP · Marine & Offshore Construction ERP · ProjectVIEW ERP and NVIDIA Omniverse

Read more: From Drone Data to Project Control: How ProjectVIEW ERP and AI Connect the Site, Yard and Offshore Reality

Why enterprise contractors need to distinguish between task-level software, project-level platforms and company-wide Construction ERP before talking about “integration”

Software surrounds construction companies today.

Scheduling software. Estimating software. Quantity take-off applications. BIM platforms. Common Data Environments. Document management systems. Procurement tools. Field applications. Accounting systems. Human Resources Management Systems. Warehouse Management Systems. Project controls platforms. Construction management platforms. Enterprise Resource Planning systems.

And almost every vendor now claims to offer an “integrated platform,” “single source of truth,” or “end-to-end solution.”

This, however, creates a fundamental problem.

In other words, we are using the same words to describe systems designed to solve completely different levels of the construction business.

• For example, a scheduling application may offer perfect integration for scheduling.
• Similarly, a Common Data Environment may provide an excellent single source of truth for project documentation.
• Likewise, a project management platform may connect hundreds of stakeholders around the delivery of one project.

Therefore, to understand construction technology properly, I believe we need to separate the market into three broad layers:

1. Purpose-specific applications

2. Project-oriented construction platforms (construction layers)

3. Company-wide Construction ERP systems

There is certainly overlap between them.

In fact, the boundaries are becoming increasingly blurred as vendors extend functionality, acquire other applications and build integration ecosystems.

But the distinction remains essential.

Because the real question is not:

“How many features does this software have?”

The real question is:

What level of the organization does the software govern?

That question changes everything.

1. Purpose-Specific Construction Applications: Solving One Problem Extremely Well

The first category includes applications designed around a specific task, discipline or operational challenge.

Examples include:

• scheduling and planning;
• quantity take-off;
• estimating;
• BIM authoring;
• document markup;
• reality capture;
• safety management;
• equipment telematics;
• payroll;
• accounting;
• procurement;
• asset maintenance;
• site reporting;
• quality management.

These applications are valuable precisely because they specialize.

For example, consider Oracle Primavera P6.

Oracle describes Primavera P6 Enterprise Project Portfolio Management as a solution for prioritizing, planning, managing and evaluating projects, programs and portfolios. Its strengths include scheduling, resources, progress monitoring and project portfolio management. Oracle also explicitly states that P6 can share data with financial, human-capital and ERP systems.

That is exactly what we should expect.

After all, Primavera does not need to become the contractor’s payroll, procurement, warehousing and General Ledger system in order to be an outstanding scheduling platform.

Its primary responsibility is different.

Likewise, specialist Quantity Take-Off systems, estimating systems, BIM applications, machinery telematics platforms and reality-capture technologies may solve their respective problems better than a large enterprise application ever could.

The strength of purpose-specific software is depth.

By contrast, its natural limitation is organizational scope.

As a result, a specialist application typically creates what we might call:

Task-Level Truth

The planner trusts Primavera for the schedule.

Similarly, the estimator trusts the estimating system for the estimate.

The BIM team trusts its model.

Meanwhile, the surveyor trusts the QTO application.

The plant manager trusts the telematics platform.

Each may be correct within its domain.

The problem begins when the enterprise needs to understand how all those truths affect one another.

2. Project-Oriented Construction Platforms: Creating Project-Level Truth

The second category emerged because construction has another unique characteristic:

One company rarely executes a project.

A large project may involve:

• the Owner;
• Engineer or Consultant;
• Main Contractor;
• Joint Venture partners;
• subcontractors;
• suppliers;
• designers;
• project managers;
• quantity surveyors;
• government authorities;
• independent inspectors.

These organizations need to exchange enormous quantities of information without necessarily belonging to the same enterprise.

They exchange:

drawings, RFIs, submittals, correspondence, change requests, inspection records, contracts, models, schedules, photos, documents and commercial information.

As a result, this created the need for project-oriented construction platforms.

Their natural organizing object is the project.

Procore

Procore is a strong example.

It provides a wide construction-management environment around project execution, field management, commercial management and project financial workflows.

But Procore’s own architecture also makes an important distinction.

For instance, its ERP Integration tools connect Procore to systems such as Viewpoint Vista, Spectrum, Sage, NetSuite, CMiC, QuickBooks, Acumatica, Workday and others. Procore describes these integrations as mechanisms to connect construction project information with the company’s ERP or accounting environment.

That does not weaken Procore’s proposition.

Instead, it helps define it.

Procore can be a very powerful construction-management layer, while another platform remains responsible for enterprise accounting and ERP functions.

Autodesk Construction Cloud

Autodesk Construction Cloud also follows a similar architectural principle.

Autodesk provides extensive construction-management capabilities and an integration ecosystem that connects Autodesk Construction Cloud with external ERP and financial applications.

In addition, Autodesk explicitly publishes guidance around connecting its construction environment with ERP and financial systems to eliminate double entry and synchronize financial information between field and back-office environments.

Again, this illustrates the difference between project execution technology and the enterprise backbone.

Oracle Aconex

Oracle Aconex provides perhaps one of the clearest examples of what I would call Project-Level Truth.

Oracle describes Aconex as a Common Data Environment — a central environment connecting organizations, processes and project information.

Aconex is particularly strong because every organization participating in a project maintains control over its information while collaborating within a common project environment. Oracle explicitly describes it as a system creating a single source of truth for the project.

That wording matters:

for the project.

In practice, Aconex can provide an authoritative project record containing documents, communications, models, approvals and decisions.

That is enormously valuable.

But project truth and enterprise truth are not necessarily the same thing.

Trimble ProjectSight

Trimble ProjectSight provides another useful example.

Trimble’s current documentation allows users to link companies and projects inside ProjectSight directly with an ERP environment. Users can then synchronize Contracts and Purchase Orders with that ERP.

Again, the architecture itself tells us something.

The project platform manages construction workflows.

Meanwhile, the ERP remains an enterprise system.

3. Company-Wide Construction ERP: Governing the Contractor, Not Just the Project

Now we reach the third category.

A contractor is not simply a collection of projects.

Above all, it is a company.

And enterprise contractors are often far more complex than that.

For example, they may consist of:

• multiple legal entities;
• subsidiaries;
• Joint Ventures;
• business units;
• regional operations;
• hundreds of simultaneous projects;
• thousands of employees;
• equipment fleets;
• production or fabrication yards;
• warehouses;
• subcontractors;
• suppliers;
• multiple currencies;
• multiple tax jurisdictions;
• different payroll regimes;
• corporate approval hierarchies;
• different Charts of Accounts.

Moreover, projects consume resources belonging to this enterprise.

And this is why Enterprise Resource Planning exists in the first place.

A company-wide Construction ERP therefore needs to manage not only the project but the relationship between the project and the enterprise.

Examples of the category include systems such as Trimble Viewpoint Vista, CMiC, Sage X3 Construction and DANAOS ProjectVIEW ERP, although their architectures, functional depth and target markets differ considerably.

Viewpoint Vista

For example, Trimble describes Vista as a fully integrated construction ERP solution covering areas including:

• job costing;
• financial management;
• payroll;
• HR;
• equipment;
• service management;
• jobsite operations;
• analytics.

Vista’s documentation illustrates exactly what enterprise integration means. For instance, payroll transactions can update Job Cost, General Ledger, Equipment Management, Accounts Payable and other financial structures.

That is more than sharing a document or synchronizing a field.

Instead, it is transactional integration.

CMiC

CMiC explicitly describes its architecture as a Construction ERP built on a Single Database Platform.

Its solution combines Construction Financials and Project Management, while Workflow and Analytics operate across both.

Its financial environment includes accounting, payroll, Human Capital Management, equipment and inventory, while its project-management environment extends into project controls, procurement, quality, safety, drawings and documentation.

Again, the important distinction is scope.

The application does not simply manage what happens inside a project.

Instead, it connects project activity directly with enterprise financial and operational processes.

Sage X3 Construction

Sage X3 Construction provides another example.

Sage positions the solution across estimating, project management, project costing, procurement, inventory, contract management, financial management, HR, payroll and analytics.

Importantly, it also supports multiple projects, currencies and business entities.

This is a characteristic of ERP.

Therefore, the system must understand both:

the project structure

and

the corporate structure.

The Categories Are Not Absolute — And That Is Important

After all, software markets are not static.

• Project-management vendors continue to add financial functionality.
• Meanwhile, ERP vendors continue to add field and project-management capabilities.
• Similarly, scheduling vendors extend into project controls.

In addition, CDE platforms increasingly support workflows, commercial processes and analytics.

Microsoft Dynamics 365 Project Operations is an excellent example of the intermix.

Microsoft provides Project Operations in different deployment configurations, including a core project-oriented environment and an environment integrated with Dynamics 365 Finance. Microsoft explicitly distinguishes between Project Operations functionality and deployments integrated with ERP.

In the ERP-integrated architecture, Microsoft synchronizes data between Dataverse and Dynamics 365 Finance using dual-write technology, while Finance provides the project-accounting and financial framework.

So this article is not trying to create artificial software boxes.

The categories describe architectural responsibility.

A platform may participate in several layers.

But ultimately, every enterprise architecture still has to answer:

Which system governs which truth?

Task Truth, Project Truth and Enterprise Truth

In short, we can reduce this distinction to three levels.

Purpose-specific application

Creates Task Truth

Project-oriented platform

Creates Project Truth

Company-wide ERP

Creates Enterprise Truth

These truths are complementary.

But they are not interchangeable.

A Common Data Environment Is Not Necessarily an ERP

This distinction deserves particular attention because CDE and Single Source of Truth have become heavily overused terms.

Oracle defines a Common Data Environment as a cloud-based environment in which authorized participants store and access construction project information.

That is an appropriate definition.

In practice, a CDE can become the authoritative environment for:

• documents;
• drawings;
• models;
• correspondence;
• revisions;
• approvals;
• project records.

But an ERP must answer a different set of questions:

• Who owns the material?
• Which warehouse contains it?
• Which supplier did the company pay?
• Which legal entity contracted the supplier?
• And which project consumed the material?
• Which cost code did it affect?
• Which accounting entry did it generate?
• What tax treatment did Finance apply?
• How did the transaction affect cash flow?
• How did it affect project profitability?

In other words, these are enterprise transactions, not simply project information.

A project CDE and enterprise ERP can — and often should — coexist.

But calling both a “Single Source of Truth” without defining the domain creates confusion.

Connectivity Is Not Integration

This may be the most important point of the entire discussion.

Today almost every enterprise application has an API.

However, that does not mean every enterprise application achieves integration.

For example, an API can send:

• a supplier number,
• a Purchase Order,
• an invoice,
• a project code,
• a cost value,
• a quantity,
• a document,
• or a status.

This proves that systems can communicate.

However, it does not prove that they share the same business logic.

By contrast, true enterprise integration requires much more.

It requires:

• common master data;
• common identifiers;
• common organizational structures;
• common workflow logic;
• transactional continuity;
• financial reconciliation;
• access governance;
• data lineage;
• accountability.

Consider a simple construction example.

A site requires 2,000 metres of cable.

The requirement should not simply become a Purchase Order.

Instead, it may need to relate to:

Project → BoQ → WBS Activity → Cost Code → Material Code → Supplier → Procurement Package → Warehouse → GRN → Site Issue → Actual Consumption → Cost → Accounting

• The schedule determines when the site requires the material.
• Procurement identifies how and from whom to source it.
• Then the warehouse records receipt.
• Site records consumption.
• Cost Control compares consumption with physical progress.
• Finance recognizes the liability and payment.
• Finally, management evaluates the impact on project profitability and cash flow.

If each department rebuilds that transaction independently in its own software, the company does not have an integrated process.

Instead, it has multiple databases periodically trying to agree with one another.

That is a very different thing.

Construction’s Digital Problem Is No Longer a Lack of Software

The industry already has enormous quantities of software.

Instead, the bigger problem is fragmentation.

McKinsey identified construction technology as a heavily fragmented and point-solution-driven market. It also observed that dissatisfaction with integrating numerous point solutions contributed to the industry’s movement toward integrated platforms.

• That observation remains highly relevant.
• We spent years digitizing individual tasks.
• Now we have to integrate the resulting digital islands.

The challenge has moved from:

“How do we digitize this process?”

to:

“How do we make all digitized processes represent the same business reality?”

Why Enterprise Contractors Need an ERP Backbone

For an enterprise-grade contractor, several things ultimately need one corporate owner.

1. Master Data

Someone must govern:

• materials,
• labor specialties,
• employees,
• suppliers,
• subcontractors,
• machinery,
• cost codes,
• companies,
• currencies,
• units of measure,
• projects,
• warehouses,
• bank accounts.

If every project application contains a different version, integration becomes permanent reconciliation.

2. Financial Consequence

Almost every construction activity ultimately has a financial consequence.

• Labor costs money.
• Materials cost money.
• Machinery costs money.
• Subcontractors cost money.
• Delays cost money.
• Change costs money.

Even progress matters commercially because progress eventually becomes:

certification → revenue → invoice → Accounts Receivable → cash.

Construction management and financial management cannot therefore remain permanently disconnected.

3. Corporate Resources

Projects do not independently own the company’s workforce, plant, supplier relationships, cash or corporate knowledge.

Instead, the enterprise owns those resources and allocates them between projects.

As a result, project execution must eventually connect back to enterprise resource management.

4. Portfolio Management

A Project Manager manages a project.

A CEO, however, does not.

Instead, the CEO manages a company containing a portfolio of projects.

Top management therefore needs consistency across:

• projects,
• business units,
• countries,
• subsidiaries,
• Joint Ventures,
• currencies,
• and reporting periods.

That level of governance requires an enterprise model.

The Right Architecture Is Not “One Application Does Everything”

This is another important distinction.

However, arguing for an ERP backbone does not mean arguing against specialist software.

That would be technologically naive.

For example, a contractor may quite legitimately use:

• Primavera P6 for scheduling.
• Revit or Tekla for design and BIM.
• Aconex as a contractual CDE.

A specialist reality-capture system for site visualization.

Specialist machinery telematics.

Specialist engineering applications.

And perhaps Client-mandated platforms that the contractor cannot replace.

The correct architectural principle is:

Specialists at the edge. ERP at the core.

The specialist applications perform the tasks they exist for.

Meanwhile, the ERP orchestrates the commercial, operational and financial consequences across the enterprise.

In short, the problem is not having many applications.

The problem is having many centers of gravity.

Where Does DANAOS ProjectVIEW ERP Fit?

DANAOS ProjectVIEW ERP belongs primarily in the third category:

Company-Wide Construction ERP

DANAOS designed ProjectVIEW as an enterprise solution for multidisciplinary, multinational and multifunctional construction organizations with dispersed operations. DANAOS technical documentation describes its modules as purpose-specific applications aligned with the departments of a construction company. However, these modules share common master files and system resources inside one centralized platform.

Its scope extends across:

• Estimation and Tendering;
• Budgeting and Cost Control;
• Procurement and Purchasing;
• Warehouse and Materials Management;
• Subcontractor Management;
• Production and Fabrication;
• Machinery and Maintenance;
• HRMS and Labor Management;
• Customer Contracts;
• Accounting and Finance;
• Documents;
• Analytics;
• workflows;
• field applications;
• external portals.

The underlying principle is important.

These modules do not operate as independent departmental islands.

Instead, they operate over a common project and enterprise structure.

In addition, DANAOS’ current SaaS architecture describes ProjectVIEW ERP as a Construction-grade ERP composed of 10+1 enterprise modules spanning Commercial, Operational, Production and Financial processes.

ProjectVIEW’s Core Construction Logic: BoQ WBS Cost Codes

Construction presents a particular ERP challenge because its fundamental dimensions come from different sources.

The Bill of Quantities — BoQ tells us what the Client expects the contractor to deliver and in what quantity.

The Work Breakdown Structure — WBS tells us how the contractor will sequence the work over time.

Finally, the Cost Code structure tells us how the contractor internally classifies expenditure and resources.

These structures relate to one another.

But they are not identical.

ProjectVIEW’s business logic therefore associates:

BoQ WBS Cost Codes

DANAOS describes this as the project kernel connecting scope, time and cost.

Internally, ProjectVIEW documentation describes the relationship as the trilateral integration of the Client’s BoQ, scheduling WBS and internal Cost Codes in order to associate cost, time and resources.

This is more important than it initially appears.

Because schedule progress alone cannot measure construction performance.

For example, imagine the site reports:

“Activity is 50% complete.”

The obvious question, then, should be:

50% according to what?

Teams may measure physical progress through quantity or percentage completed against the relevant BoQ or WBS.

But Cost Control requires a second question:

What resources did the work consume to achieve that 50%?

Labor.

Materials.

Machinery.

Subcontractors.

Indirect resources.

If the achieved quantity, production rate, time and consumed cost do not align with the baseline, then something has changed.

That is the point where construction management becomes economic control, not simply progress reporting.

Why ProjectVIEW Still Integrates with Primavera, BIM, SAP and Oracle

If ProjectVIEW is an ERP, why integrate with other systems?

Because an enterprise backbone should not become an excuse for technological isolation.

ProjectVIEW connects with specialist construction technologies including Oracle Primavera P6, Microsoft Project and BIM environments.

It can also connect with third-party enterprise platforms such as SAP or Oracle through APIs when required. DANAOS technical documentation explicitly provides for these hybrid architectures.

This matters particularly for very large multinational groups.

For example, a holding company may have standardized globally on SAP or Oracle for Finance.

Replacing that platform may be neither commercially realistic nor technologically necessary.

In that scenario:

SAP/Oracle may remain the Corporate Financial ERP, while

ProjectVIEW becomes the Construction Operating Layer managing deeper construction-specific processes.

That is a legitimate architecture.

The same software can therefore play different roles depending on the deployment.

So What Should “Single Source of Truth” Actually Mean?

It should not mean that every byte of data must physically live in one database.

That definition no longer holds.

Instead, a modern enterprise can legitimately operate several systems of record.

The requirement is that ownership is unambiguous.

For example:

• Primavera may own the approved schedule.
• The BIM environment may own the current model.
• Aconex may own the contractual document record.

Finally, the ERP may own supplier, employee, accounting, procurement and cost transactions.

The important thing is that all participating systems know:

which system owns which truth,

which identifiers connect them,

and

how a transaction moves between them without losing meaning.

That is enterprise architecture.

How Should Contractors Test Whether a Platform Is Truly Integrated?

Instead of asking a vendor:

Ask the following:

Where is master data created?

Who owns suppliers, materials, employees, machinery, Cost Codes, organizations and projects?

Can transactions maintain their identity?

Can a requirement move from site request to procurement, Purchase Order, receipt, consumption, cost and finance without anyone recreating it?

Can the system reconcile physical progress with resource consumption?

Can management understand whether the quantity of work delivered justifies the cost incurred?

Can the system manage the corporate structure?

• Multiple companies?
• Subsidiaries?
• Joint Ventures?
• Countries?
• Currencies?
• Projects?

Can operational activity reach Finance?

Does the construction transaction eventually create an auditable financial consequence?

Can executives compare projects consistently?

Or does Business Intelligence first have to normalize ten different data structures?

Can users trace a KPI back to its transaction?

If management sees a cost variance, can users drill down to determine the labor, material, machinery, subcontractor or procurement transaction responsible?

These questions reveal much more than a feature comparison.

Where Does AI Fit Into This?

There is another reason why this discussion has become urgent.

AI.

Companies are now racing to introduce AI agents, copilots and predictive systems into construction.

But AI multiplies the quality of the data and processes beneath it.

If the enterprise contains conflicting supplier records, inconsistent Cost Codes, disconnected schedules, duplicate material definitions and unreconciled project financials, AI does not magically create enterprise truth.

Instead, it accelerates the consumption of inconsistency.

This is why structured ERP data becomes strategically important.

ProjectVIEW’s current architecture positions ERP as the structured process and data layer beneath its AI environment, using BoQ, WBS and Cost Codes as machine-understandable project dimensions.

Before organizations pursue autonomous construction AI, they need something much less glamorous but much more important:

consistent enterprise data.

Frequently Asked Questions

What is the difference between Construction Management Software and Construction ERP?

Construction Management Software primarily helps coordinate and control the execution of projects.

By contrast, Construction ERP connects project execution with enterprise functions such as procurement, inventory, payroll, machinery, accounting, finance, corporate resources and portfolio management.

Is Procore an ERP?

Procore provides extensive construction-management and project-financial functionality, but Procore itself provides dedicated integrations to multiple ERP and accounting systems. This illustrates its ability to coexist with an enterprise ERP backbone rather than requiring Procore itself to perform every ERP function.

Is Autodesk Construction Cloud an ERP?

Autodesk Construction Cloud is primarily a construction and project-delivery environment. However, Autodesk actively supports integrations with external ERP, accounting and financial applications.

Is a CDE the same thing as ERP?

No.

A CDE manages shared project information and collaboration.

By contrast, an ERP manages enterprise resources, transactions and financial consequences.

They can and often should operate together.

Does ERP eliminate specialist applications?

No.

A mature enterprise architecture should retain specialist applications when those applications provide superior domain functionality.

Instead, ERP should orchestrate them.

Can a generic ERP such as SAP, Oracle or Dynamics operate as the enterprise backbone?

Absolutely.

Large enterprise ERP platforms can provide the corporate backbone.

However, the question for contractors is whether the system natively contains enough construction-specific business logic or whether it needs an additional construction operating layer.

Is ProjectVIEW ERP only a project-management platform?

No.

ProjectVIEW ERP’s architecture extends across Commercial, Operational and Financial processes, with multi-company and multi-project capabilities and construction-specific modules sharing common enterprise data.

Can ProjectVIEW coexist with SAP or Oracle?

Yes.

DANAOS supports integration with external ERP environments when a larger corporate group wishes to retain its existing corporate financial platform.

The Real Digital Transformation Question

For the last decade, construction has focused heavily on digitizing individual processes.

That was necessary.

But we are entering the next stage.

The challenge is no longer simply:

“Can we digitize this task?”

Instead, the challenge is:

“Can we make every digital process describe the same business reality?”

That requires architecture.

It also requires governance.

Equally, it requires master data.

It requires transactional continuity.

Above all, it requires the connection of the site with the office, the project with the company, and ultimately the physical progress of construction with its financial consequence.

Purpose-specific applications will remain essential.

Project collaboration platforms will remain essential.

CDEs will remain essential.

Scheduling applications will remain essential.

BIM will remain essential.

But enterprise contractors still need something at the center.

Something must understand the company.

It must also understand its resources.

Something must understand every project.

In addition, it must convert construction activity into cost, revenue, cash flow and profitability.

Finally, it must reconcile:

What we promised to build

When we planned to build it What resources we consumed What it actually cost And what value we earned

That is the role of the Construction ERP.

Purpose-specific applications optimize tasks.

Project-oriented platforms coordinate projects.

Construction ERP governs the enterprise.

And this is precisely where DANAOS ProjectVIEW ERP aims to operate:

not as another application surrounding the construction project, but as the construction-specific enterprise backbone orchestrating the company behind it.

Sources and Further Reading

LinkedIn — AI Search Visibility Guidelines LinkedIn recommends long-form articles as authority-building assets and emphasizes clear terminology, question-based headings, standalone answer sections and consistent category language for AI retrieval. LinkedIn: How to Maximize AI Visibility for Your LinkedIn Posts

McKinsey — Construction Technology Fragmentation and Platform Integration McKinsey: Rise of the Platform Era — The Next Chapter in Construction Technology

Oracle Primavera P6 Enterprise Project Portfolio Management Oracle Primavera P6 EPPM

Oracle Aconex — Project Collaboration and Common Data Environment Oracle Aconex Construction Project Management

Procore ERP Integrations Procore ERP Integrations Documentation

Autodesk Construction Cloud — ERP and Financial Integration Autodesk: Construction ERP and Financial Integrations

Trimble ProjectSight — ERP Integration Trimble ProjectSight ERP Integration

Trimble Viewpoint Vista — Construction ERP Trimble Vista Construction ERP

CMiC — Construction ERP CMiC Construction ERP Platform

Sage X3 Construction Sage X3 Construction ERP

Microsoft Dynamics 365 Project Operations Microsoft Dynamics 365 Project Operations Documentation

DANAOS — ProjectVIEW OS and BoQ WBS Cost Codes Architecture ProjectVIEW OS: The Operating System for Construction

DANAOS — Why ERP Comes Before AI Walk Before You Run: Why ERP Comes Before AI

DANAOS — ProjectVIEW ERP SaaS Architecture and Functional Scope DANAOS ProjectVIEW ERP Master SaaS Framework

Read more: Construction Software Is Not One Market: Point Solutions, Project Platforms and Construction ERP Explained

Defence and space manufacturing is not simply manufacturing. It is project execution in which manufacturing is nested inside a larger contractual, engineering and delivery scope.

A radar installation, mission-support facility, satellite integration structure, specialised ground-support system or engineered module is rarely the output of a repetitive production line operating independently of a project.

It exists because a specific project requires it.

That distinction changes the ERP logic completely.

In conventional manufacturing, the Bill of Materials (BoM) is usually the dominant structure: what components does it take to manufacture a product?

For simplicity, this article uses BoQ as that commercial/project anchor.

The critical requirement is therefore not merely managing a BoM.

Instead, it is creating a digital chain that can translate:

Project Requirement → BoQ → WBS → Fabricated Product → BoM → Production Operations → Quality → Assembly/Installation → Cost → Progress

That is the difference between manufacturing software and a true project-based manufacturing ERP.

DANAOS ProjectVIEW ERP already models this relationship through its Project-Based Manufacturing ERP architecture, where users can transform a project BoQ into production-ready BoMs and routings that remain connected to WBS activities and cost codes. danaos-projects.com

What is project-based manufacturing in Defence and Space?

Project-based manufacturing is the production of engineered items specifically required to fulfil a project, contract or mission scope rather than to replenish a standard inventory of repetitive products.

In practice, this commonly overlaps with engineer-to-order and low-volume/high-complexity manufacturing.

However, the important distinction is economic as much as technical.

In other words, the manufactured item does not exist as an isolated product.

Instead, it exists inside the economics and schedule of the project that requires it.

NASA’s Systems Engineering Handbook reflects the broader systems-engineering reality of the space sector: development and product realization are iterative, multidisciplinary processes extending across the project lifecycle. In addition, NASA specifically highlights Model-Based Systems Engineering as a mechanism for improving product development and delivery. NASA

Similarly, European space programmes operate within the European Cooperation for Space Standardization framework, which explicitly integrates project management, engineering, industrialisation, production, maintenance and product assurance. Its configuration-management standard requires maintaining the relationship between product characteristics, approved requirements and the evolving as-built configuration throughout the lifecycle. ECSS

This is exactly why conventional departmental separation becomes problematic.

Engineering cannot finish its job and simply “throw the BoM over the wall” to production.

Similarly, production cannot manufacture without understanding project milestones.

Procurement cannot buy solely against inventory demand.

Likewise, quality cannot operate separately from configuration.

And Finance cannot understand true project performance if fabrication costs sit apart from the project deliverable that caused them.

The missing translation: BoQ → BoM

This is the architectural problem that deserves more attention.

For example, imagine a project BoQ contains a requirement for an engineered assembly.

From the project’s perspective, that assembly may appear as one material or product required to complete one BoQ design scope.

But internally, that “material” is not necessarily something purchased from a catalogue.

Instead, it may itself be a project-based manufactured product.

In turn, that product expands into its own BoM consisting of multiple raw materials, bought-out components, consumables and semi-finished items.

• It also requires labour.
• In addition, it consumes machinery, tools and production capacity.
• It follows manufacturing operations.
• Finally, it passes through inspection and quality gates.

Certain processes may take place internally.

Others may go to specialised suppliers or subcontractors.

Finally, once complete, the manufactured output collapses back into a single identifiable product that the parent project scope consumes during assembly, erection, integration or installation.

We call this nested project manufacturing.

ProjectVIEW already supports the underlying logic through BoQ-to-BoM manufacturing, production phases and resource allocation and through its dedicated Materials & Production Management module. Production phases can be sequential or parallel and can distinguish inputs, semi-finished products and outputs. They can also allocate labour and machinery, incorporate subcontractors, calculate final production-unit cost and compare planned versus actual resources and costs. Danaos Projects

That creates a much richer relationship than:

Product → BoM

Instead, it becomes:

BoQ Scope → WBS Activity → Manufactured Product → BoM + Routing + Resources + Quality → Finished Product → Parent BoQ

And every layer remains economically attributable to the same project.

A manufactured product is also a project resource

This concept is particularly important.

A manufactured assembly can simultaneously be:

For example, consider an engineered support module fabricated for a defence programme.

At the project level it may be a material/resource required for a defined BoQ work package.

Internally, however, ProjectVIEW can explode that product into a manufacturing BoM.

In turn, its fabrication may require structural materials, bought-out components, specialist labour, welding or machining equipment, quality inspections and perhaps outsourced finishing or specialist testing.

Once the assembly passes acceptance, the team returns it to the parent project as a controlled, identifiable resource ready for installation.

The important point is that its cost has not disappeared into a generic factory overhead account.

Instead, its labour hours, machine time, materials, subcontracted operations and production progress remain attributable to the project requirement that created it.

That is project cost control reaching inside manufacturing.

Defence example: one BoQ requirement, an entire production project underneath

For example, consider a defence contractor delivering an integrated mission-support facility.

One contractual scope item may require an engineered equipment enclosure or structural module.

From the parent project perspective, management wants to know:

• Is it ready?
• When will the team install it?
• What did it cost?
• Has it passed inspection?
• Is it using the approved configuration?

But underneath that apparently simple item sits a mini-project.

• First, engineering releases drawings and specifications.
• Then the system generates or associates the relevant BoM and routing.
• Procurement secures required components.
• Production allocates shop capacity, labour and machinery.
• Specialist suppliers can take on selected processes.
• Quality records inspections, non-conformances and approvals.
• The system version-controls configuration changes.

Finally, the team serializes or otherwise identifies the finished item and transfers it to the required yard or site. Its parent installation activity then consumes it.

They become different views of the same project reality.

DANAOS applies comparable fabrication logic today in complex project environments such as shipbuilding and shipyard operations, where fabrication, materials, labour, subcontractors, design information, production and cost are already intertwined. Danaos Projects

Space example: manufacturing is inseparable from configuration and quality

Now consider a specialised ground-support structure or integration frame produced for a space programme.

Its BoM may contain standard items, specially manufactured components and precision parts obtained from specialist suppliers.

• Some production takes place in the manufacturer’s shop.
• A specialist supplier may perform another operation.
• Final assembly may occur in a different facility.
• Acceptance may require inspection records, certificates, approved drawings and a precise as-built configuration.

This is why quality cannot simply be another ERP module sitting beside manufacturing.

Instead, quality is part of the production state.

The European space standards make this relationship explicit: ECSS maintains dedicated requirements for space product assurance, quality assurance for space projects and configuration/information management. ECSS

Therefore, no one can truthfully report a manufactured item as “complete” merely because fabrication operations reached 100%.

• For example, it may be physically complete but not inspected.
• Inspected but subject to a non-conformance.
• Accepted but not released.
• Released but not transported.
• Delivered but not integrated.
• Integrated but waiting for final verification.

Each state means something different to Production, Quality, Planning, Commercial Management and the customer.

Therefore, a serious ERP must understand those differences.

In Defence and Space, real-time information is not enough. It must be high-confidence information.

This is perhaps the most important distinction.

Executives often ask for “real-time dashboards.”

But speed without confidence is dangerous.

If a report tells a programme director that an assembly is 82% complete, what exactly does 82% mean?

• Hours consumed?
• Operations completed?
• Physical quantities produced?
• BoM items completed?
• Quality-approved output?
• Earned value?
• Shop-floor self-reporting?

The objective should therefore be high-confidence real-time progress.

Instead, evidence from the underlying processes should support every progress statement: manufacturing operations, consumed materials, labour transactions, machine activity, subcontractor milestones, inspection status, approved documentation and schedule position.

For example, the U.S. Digital Engineering Strategy calls for authoritative sources of system data and models spanning disciplines and the lifecycle. It explicitly links such an authoritative source of truth to managing cost, schedule, performance and risk, while stressing that stakeholders require the right information at the right time. Assistant Secretary of War

That principle translates directly into project-based ERP.

Teams should not merely report progress. They should prove it.

Where AI changes Defence and Space project manufacturing

ProjectVIEW ERP provides the structured process and data layer. DANAOS describes ProjectVIEW OS and ProjectVIEW AI as an intelligence layer operating over structured BoQ, WBS, cost and operational information. Published areas include cost-deviation prediction, delay and productivity forecasting, risk scoring, procurement intelligence, anomaly detection and AI-assisted workflows. Danaos Projects

For Defence and Space manufacturing, this opens several particularly valuable use cases:

1. AI-validated progress. An AI agent can compare declared production progress against BoM completion, consumed materials, labour transactions, machine activity, subcontractor status and passed quality gates. Instead of simply repeating “75% complete,” it can flag that only 61% of the evidence supports the reported state and identify what is missing.
2. AI schedule and production-risk forecasting. If a specialist component arrives late, one machine is unavailable and a mandatory inspection has moved, AI can evaluate their combined effect on the production routing, WBS activity and ultimate project milestone—rather than analysing each problem in isolation.
3. AI quality and configuration intelligence. Document intelligence can identify missing inspection records, inconsistent drawing revisions, incomplete certificates, recurring non-conformance patterns or transactions executed against superseded information. The objective is not to replace engineering judgement but to surface contradictions before they propagate downstream.

How can AI support procurement and stakeholder decisions?

4. AI procurement and make-or-buy intelligence. Because the company can produce a fabricated product internally or outsource it, AI can compare internal capacity, machine availability, historical productivity, supplier lead times, procurement commitments and forecast cost before management decides whether to make, subcontract or purchase.
5. AI executive and stakeholder briefings. An authorised stakeholder could ask: What is the current approved status of Package X, what is blocking completion, what is its latest forecast cost and which evidence supports that assessment? The AI can then generate its response from structured ERP transactions and linked evidence rather than manually assembled emails and spreadsheets.

The critical word throughout is evidence.

AI becomes substantially more valuable when it reasons over controlled operational data rather than trying to reconstruct project truth from disconnected documents.

Confidentiality changes how collaboration must work

Defence and space programmes introduce another requirement: not every stakeholder should see everything.

• Real-time visibility does not mean unrestricted visibility.
• Programme leadership may need cost and schedule exposure.
• Production management needs detailed manufacturing status.
• Quality teams need inspection and non-conformance information.
• Specialist contractors may require only their assigned work package.
• Customers may require approved milestone status without access to internal commercial or supplier information.

The correct architecture is therefore:

one source of truth, multiple authorised views.

In U.S. environments handling Controlled Unclassified Information, NIST SP 800-171 Rev.3 provides an important benchmark: it addresses protection of CUI in non-federal systems and includes access control, least privilege, auditability, system integrity and protection of information in transit and at rest. It specifically requires limiting users and processes to the access necessary for their assigned functions and maintaining detailed audit records. NIST Publications

However, this does not mean that using an ERP automatically establishes compliance with NIST, ECSS, export-control rules or a particular defence contract. Organisations must always validate compliance against the specific programme, jurisdiction, data classification and contractual obligations.

But it defines the correct architectural direction.

Therefore, the system should distribute project information according to identity, role, responsibility and need-to-know.

For example, notifications to sensitive stakeholders should ideally announce that a significant event exists and provide authenticated access to the authoritative record. They should not unnecessarily distribute confidential technical or commercial information through uncontrolled channels.

ProjectVIEW’s integrated CDE already supports document versioning, approvals, history and audit trails, while its manufacturing environment connects production activity to the originating project structure. ProjectVIEW document control and CDE capabilities Danaos Projects

From digital thread to economic thread

The Defence and Space sectors already understand the digital thread.

Industry technology providers describe it as the continuous connection between engineering, manufacturing, production and lifecycle information. Siemens, for example, positions the aerospace and defence digital thread around programme management, engineering, supply chain, production and product support. Siemens Resources

But there is another thread that is just as important:

the economic thread.

• A design decision has a cost.
• Similarly, a BoM revision has a procurement consequence.
• A late component has a schedule consequence.
• Machine downtime changes production economics.
• A rejected part consumes labour and materials without producing accepted progress.
• An outsourced process creates commitment, schedule and quality dependencies.
• A configuration change can invalidate work already performed.

ProjectVIEW’s project-based logic connects that physical and engineering reality back to the BoQ, WBS and Cost Codes.

As a result, the digital thread does not end at engineering or the shop floor.

Instead, it continues into budget, commitments, actual cost, earned value, project progress and financial performance.

Why conventional manufacturing ERP is not enough

A conventional manufacturing ERP may be very good at answering:

What does it take to manufacture Product A?

By contrast, Defence and Space project manufacturing requires a broader question:

Why are we manufacturing Product A, for which contractual requirement, against which schedule milestone, using which resources, under which configuration, at what cost, with what quality status, and how does its completion affect the parent programme?

That question crosses engineering, project controls, procurement, production, quality, subcontracting, logistics and finance.

However, no one can answer it reliably when those functions live in disconnected systems.

Nor can AI answer it if AI itself has no structured operational truth underneath it.

This is the significance of ProjectVIEW’s BoQ-to-BoM project manufacturing model.

The BoM explains how to build the product. Then the WBS explains when the team must build it. The BoQ explains why the project needs it and where its economic value sits. Cost Codes explain what its execution is costing the enterprise. Quality and configuration records establish whether the output is actually acceptable.

Project-based manufacturing connects all five.

AI can then interpret the resulting digital fabric.

The Defence & Space manufacturing ERP should become a command system, not a database

For complex Defence and Space programmes, the objective is not another system of records.

Instead, it is a controlled project-manufacturing command environment.

One capable of following a requirement from contractual scope to engineering definition; from BoQ to BoM; from procurement to fabrication. It should also follow work from internal shop to external specialist contractor and from production to inspection. Finally, it should trace work from finished component to assembly and erection, and from physical execution back to time, cost, quality and programme performance.

In these environments, a manufactured item may be a product today, a project resource tomorrow and part of a much larger system after installation.

Therefore, the information system must understand all three states.

That is project-based manufacturing.

And that is precisely the type of complexity that an integrated, project-centric ERP such as DANAOS ProjectVIEW ERP exists to handle.

FAQ: Defence & Space Project-Based Manufacturing

What is the difference between a BoQ and a BoM?

A BoQ represents project or contractual scope and quantities, while a BoM describes the components required to manufacture a product. In project-based manufacturing, the important capability is maintaining the relationship between them so that manufactured products remain linked to the project requirement, WBS activity, budget and cost structure that created the demand.

What does BoQ-to-BoM mean?

BoQ-to-BoM means taking a project deliverable or fabricated item defined within the commercial/project structure and expanding it into the materials, components, operations and resources necessary to manufacture it. Once completed, the manufactured product returns to the parent project as a controlled resource for assembly, erection or installation.

Why is project-based manufacturing important for Defence and Space?

Because engineers design many Defence and Space deliverables for a specific programme, configuration or mission rather than for repetitive stock. They therefore require simultaneous control of engineering, manufacturing, project schedule, quality, procurement, subcontracting and cost.

How can AI improve Defence and Space manufacturing ERP?

AI can compare reported progress with operational evidence, predict production and procurement risks, detect anomalies, review documentation, identify configuration inconsistencies and provide authorised stakeholders with evidence-based project briefings. However, its reliability depends heavily on the quality and structure of the ERP data underneath it.

Why is secure stakeholder visibility important?

Because sensitive programmes require both rapid information flow and strict information control. The objective is not to expose all project information to everyone, but to give each authorised stakeholder the right verified information, at the right time, for the right purpose.

Read more: Defence & Space Manufacturing ERP: Why Project-Based Manufacturing Starts with BoQ-to-BoM

“The project is 50% complete.”

It sounds precise.

But in construction, infrastructure, EPC, shipbuilding, offshore works, mining development and project-based manufacturing, it may be one of the most ambiguous statements management can hear.

In fact, there is no universal construction percentage called simply “percent complete.”

50% according to whom?

• The planner?
• The site engineer?
• Or the quantity surveyor?
• The subcontractor?
• The cost controller?
• Or the consultant?
• Finance?
• The client?

Because a project can simultaneously be:

All of those numbers may be correct.

However, they are simply measuring different realities.

And that is precisely why management must not confuse progress reporting with Construction Management.

The real question is not only:

It is:

That is where progress measurement becomes Cost Control.

And that is where Earned Value becomes meaningful.

What Does “50% Complete” Actually Mean?

Even Oracle Primavera P6 distinguishes between different completion measures, including Duration Percent Complete, Units Percent Complete, Physical Percent Complete and Performance Percent Complete. P6 then uses Performance Percent Complete in Earned Value calculations. Oracle Primavera P6 activity and percent-complete definitions

That distinction is fundamental.

For example, a scheduling application may legitimately report that an activity is 50% complete according to its selected progress methodology.

But that does not automatically establish:

• that the team has constructed 50% of the contracted quantity;
• that the work has consumed 50% of the required resources;
• nor that the project has earned 50% of the budget;
• that the operation is producing at the planned rate;
• or that the project is economically healthy.

Time is not quantity.

Quantity is not cost.

Cost is not progress.

Construction Management begins when the organization relates those dimensions to each other.

Record Progress Where It Actually Happens: On Site

Actual construction progress originates from execution.

It happens on the construction site, fabrication yard, shipyard, workshop, mine, offshore facility or wherever crews perform physical work.

Teams should therefore capture progress against the actual scope of work.

Depending on the nature of the activity, teams can register it as:

• an actual quantity completed against a BoQ item;
• a percentage completed against a WBS activity;
• measurable production against both the BoQ and associated WBS;
• or a predefined weighted completion methodology where quantities alone are not sufficient.

In practice, the examples are straightforward:

• 500 m of 1,000 m pipeline installed = 50% physical quantity progress
• 600 m³ of 1,000 m³ concrete poured = 60%
• 250 tonnes of 500 tonnes structural steel erected = 50%
• 25 of 50 equipment units installed and accepted = 50%

For work that no one can sensibly measure as a continuous quantity, predefined progress milestones or Rules of Credit can establish how the work earns completion.

InEight, for example, describes Rules of Credit as a method of assigning progress to measurable milestones so that progress reporting reflects verified accomplishment rather than subjective judgement. InEight — Rules of Credit Drive Reliable Construction Budgeting

This establishes the first principle:

But even accurate physical progress is only half of the equation.

The Missing Question: What Did It Take to Produce That Progress?

For example, assume a pipeline activity contains:

BoQ quantity: 1,000 metres Actual installed quantity: 500 metres

The site then legitimately reports:

50% complete.

But now management needs to know something much more important.

What did we consume to produce those 500 metres?

How many:

• labor hours;
• machinery hours;
• materials;
• subcontractor resources;
• consumables;
• indirect resources;

did the work require?

And how does that compare with what we originally budgeted?

A Simple Example Shows the Problem

For example, imagine the budget for 1,000 metres of pipeline assumed:

800 labor hours

80 machinery hours

1,000 metres of pipe

plus associated subcontractor and indirect costs.

At exactly 50% physical completion, proportional planning assumptions would suggest approximately:

400 labor hours

40 machinery hours

500 metres of material

as the expected consumption, subject of course to the actual resource-loading and production profile.

But site transactions reveal:

560 labor hours

55 machinery hours

540 metres of materials

as actual consumption.

• The project is indeed 50% physically complete.
• But its resource performance is not 50%.
• Labor has already consumed 70% of the planned labor hours.
• Machinery has consumed almost 69% of the planned machinery hours.
• Material consumption is at 54%.

But the resources required to produce that progress are diverging from the budget assumptions.

That divergence is where the real management problem begins.

Quantity + Time + Cost: The Construction Reality Check

The essential relationship in construction is therefore not simply:

Planned Progress vs Actual Progress

It is:

Each one tests the others.

Quantity answers:

What have we actually built?

Time answers:

How quickly are we producing it (effort-drive production)?

Resources answer:

What did we consume to produce it?

Cost answers:

What did that resource consumption cost us?

In short, a healthy operation requires these dimensions to remain reasonably aligned with the assumptions contained in the project budget and schedule.

That is the reality check.

Production Rate Is as Important as Progress

For example, suppose our original budget assumed:

• 1,000 metres of work using 800 labor hours.

The budgeted productivity is therefore:

• 1.25 metres per labor hour.

But after completing 500 metres, the crew has consumed 560 labor hours.

Actual productivity is now:

• 0.89 metres per labor hour.
• Physical progress is still accurately reported at 50%.

But labor productivity has deteriorated substantially against the budget assumption.

A progress dashboard that simply reports:

cannot expose this.

The percentage is correct.

The management conclusion is wrong because the percentage exists without operational context.

This is why management must calculate actual labor productivity by relating resource consumption to the work actually produced.

This Is What Earned Value Is Trying to Tell Management

At project-control level, Earned Value Analysis formalizes this relationship by comparing three fundamental dimensions:

• Planned Value (PV): How much value should the project have completed by now?
• Earned Value (EV): What is the budgeted value of the work actually completed?
• Actual Cost (AC): What did the completed work actually cost?

For example, suppose our pipeline work package has a Budget at Completion of $100,000.

At the reporting date:

Planned progress = 60%

Therefore:

PV = $60,000

But verified physical progress is only:

50%

Therefore:

EV = $50,000

And actual resources consumed have generated:

AC = $65,000

The project is therefore behind plan and spending disproportionately against the value it has earned.

The Schedule Performance Index is:

SPI = EV / PV = 0.83

The Cost Performance Index is:

CPI = EV / AC = 0.77

Oracle Primavera’s current API definitions similarly describe Earned Value as the baseline budget multiplied by Performance Percent Complete and SPI as Earned Value divided by Planned Value. Oracle Primavera P6 Earned Value and schedule-performance definitions

This is why Earned Value is powerful.

It does not simply ask:

It asks:

And that is fundamentally a Construction Management question.

Earned Value Must Still Rest on Actual Construction Reality

However, Earned Value is only as reliable as the progress measurement feeding it.

If somebody simply types:

50% complete

against a WBS activity without a defensible relationship to physical accomplishment, the resulting Earned Value calculation may be mathematically perfect and operationally meaningless.

This is an important distinction.

Therefore, the system must know what constitutes earned progress.

That may come from:

• installed quantities;
• completed BoQ quantities;
• verified WBS progress;
• weighted steps;
• Rules of Credit;
• accepted production outputs;
• inspected work;
• or another objectively defined measurement method.

The objective is always the same:

Not optimism.

Nor expenditure.

Not simply elapsed time.

Why WBS-Only Progress Is Not Enough

The WBS is indispensable.

It structures:

• activities;
• sequence;
• dependencies;
• milestones;
• duration;
• project time.

But the WBS cannot, by itself, represent the entire economic reality of construction.

For example, consider an activity:

Install Chilled Water Piping — Level 3

The schedule may know:

• start date;
• finish date;
• duration;
• logic;
• resource assignments;
• percent complete.

But commercial and operational control needs considerably more.

• What quantity of pipe exists within that activity?
• Which BoQ lines?
• Which diameters?
• What materials?
• Which labor specialties?
• What machinery?
• Which subcontractor?
• What budget?
• What cost?
• Which items has procurement bought?
• What has arrived?
• How much has the work consumed?
• What have inspectors checked?
• Which quantities has the client certified?
• What has been paid?

A WBS activity represents the execution structure of time.

However, it does not automatically represent the full commercial and financial structure of the project.

This is precisely why ProjectVIEW ERP uses the relationship:

• The BoQ establishes the measurable and commercial scope.
• The WBS establishes execution and time.
• Cost Codes establish the enterprise’s economic classification of resource consumption.

ProjectVIEW then connects actual project transactions to those structures.

A WBS Progress Update Is a Report. It Is Not Yet Cost Control.

This distinction needs to be explicit.

When somebody updates an activity from:

40% → 50%

the organization has recorded progress.

Useful? Absolutely.

Necessary? Yes.

Construction Management? Not yet.

Management still needs to determine whether the exploitation of resources associated with the same work justifies that progress.

If 10% additional progress required:

• 10% of the expected labor,
• plus 10% of expected plant,
• 10% of expected materials,

and approximately the expected time,

the operation may be tracking well.

But if that same additional 10% progress required:

• 22% additional labor,
• 18% additional machinery cost,
• 15% excess material consumption,

and twice the expected duration,

management has discovered a serious performance problem.

• The schedule alone cannot explain it.
• Equally, the progress percentage alone cannot explain it.
• The accounting ledger alone cannot explain it.

Only the relationship between work achieved and resources consumed explains it.

This Is the Difference Between Reporting and Construction Management

A scheduling system can tell management:

By contrast, a construction management and cost-control system must answer:

That is a profoundly different level of control.

A standalone percentage is reporting.

However, a quantity of completed work reconciled with time, resources and cost is Construction Management.

Labor Hours Do Not Equal Progress

For example, consider two projects.

Both report:

• 50% physical progress.

Project A has consumed:

• 48% of its budgeted labor hours.

Project B has consumed:

• 72%.

Should management regard them as equally healthy because both are 50% complete?

Clearly not.

Project A is broadly tracking its planned labor productivity.

By contrast, Project B is converting substantially more labor into the same physical output.

The difference may arise from:

• poor site conditions;
• learning curve;
• congestion;
• rework;
• poor supervision;
• inadequate materials availability;
• design changes;
• access restrictions;
• overtime;
• inappropriate crew composition;
• or incorrect estimating assumptions.

Whatever the cause, the problem becomes visible only when labor consumption and physical achievement share the same project reference.

This is why ProjectVIEW treats labor productivity as part of project control rather than merely HR administration.

Machinery Hours Do Not Equal Progress Either

The same logic also applies to plant.

For example, a crane booked for ten hours has not necessarily produced ten hours of value.

Similarly, an excavator present on site may be:

• working,
• waiting,
• idle,
• under maintenance,
• mobilizing,
• or blocked by another activity.

The question is not merely:

It is:

ProjectVIEW’s machinery-management model includes work and idle cost, scheduling and availability, logistics, maintenance and BoQ-related daily machinery utilization.

Therefore, ProjectVIEW can treat machinery as an economic resource associated with actual project production—not simply as an asset in a fleet register.

Materials Arriving on Site Are Not Progress

Materials introduce another common distortion.

Suppose:

The team has purchased 70% of the materials.

Is the work 70% complete?

Of course not.

What if:

• procurement has ordered 70%,
• 60% delivered,
• 55% received into inventory,
• 45% issued from the warehouse,
• 40% installed,
• and only 35% inspected and accepted?

Which percentage represents progress?

Each transaction tells management something useful.

However, management should not confuse one with another.

ProjectVIEW’s materials and production processes distinguish:

• procurement;
• Goods Receipt Notes;
• inventory;
• warehouse movements;
• issues;
• production phases;
• resource consumption;
• and actual production cost.

That distinction is critical in:

• construction,
• MEP fabrication,
• structural steel,
• modular construction,
• shipbuilding,
• ship repair,
• offshore fabrication,
• industrial manufacturing,

and other project-based production environments.

• Ordered is not received.
• Received is not consumed.
• Consumed is not installed.
• Installed is not necessarily accepted.

And none of these percentages should blindly become “project progress.”

Yard Progress Is Not Automatically Site Progress

This becomes even more important when projects combine manufacturing and construction.

Suppose a modular unit is:

• 80% fabricated in the yard.

Is the associated project work 80% complete?

• Perhaps not.

The module may still require:

• testing;
• inspection;
• painting;
• release;
• transportation;
• lifting;
• erection;
• connection;
• commissioning;
• and client acceptance.

Project-based manufacturing therefore needs progress control across multiple physical environments:

The economic thread must remain continuous while the physical product moves.

Otherwise each department reports its own version of “completion.”

Subcontractor Claimed Progress Is Another Version of Reality

A subcontractor may submit:

55% complete.

However, that is not necessarily the percentage the main contractor should recognize.

The main contractor may need to validate actual progress against:

• measured quantities;
• inspection records;
• contract rates;
• previous certifications;
• approved variations;
• retention;
• deductions;
• nonconformities;
• and supporting documents.

Therefore:

Claimed Progress ≠ Verified Progress

and:

Verified Progress ≠ Certified Progress

ProjectVIEW’s subcontractor processes connect subcontractor contracts, site progress, certifications, deductions and financial consequences within the project-control structure. DANAOS describes ProjectVIEW’s integrated environment as including subcontractor progress, certifications and liabilities alongside project Cost Control.

Certified Progress Is Not the Same as Physical Progress

A contractor may genuinely have completed:

50% of the physical work.

But perhaps:

• inspectors have checked 47%,
• the client has formally certified 43%,
• the contractor has invoiced 38%,
• and the client has actually paid 30%.

Again, none of those percentages is necessarily wrong.

They belong to different stages in the conversion of work into commercial value.

This gives us an important sequence:

Construction ERP should preserve those distinctions while maintaining the relationships between them.

Because operational execution eventually has to become financial reality.

This Is Where Project Accounting and Financial Accounting Must Meet

Financial accounting can accurately report:

• invoices;
• payables;
• receivables;
• journal entries;
• payments;
• revenue;
• expenses.

But accounting normally sees the financial consequence only after Finance recognizes the transaction.

Construction Management must also understand what is happening operationally before all financial documents arrive.

• A supplier may have delivered materials whose invoice Finance has not yet posted.
• A subcontractor may have completed work that the client has not yet certified.
• The project may already have consumed labor before payroll closes.
• Machinery may have worked before Finance finalizes the monthly cost allocation.
• Physical progress therefore exists before parts of its cost reach the general ledger.

Again:

BoQ WBS Cost Codes

This is where financial accounting and project accounting converge.

Cost Control Happens When Resource Consumption Justifies Progress

We can now define Cost Control more precisely.

Cost Control is not merely knowing:

• Actual Cost vs Budget.

Instead, it is understanding why the actual cost exists in relation to the work achieved.

For example, suppose two work packages have each spent:

• $500,000.

Package A has earned:

• $550,000 of budgeted value.

Package B has earned:

• $350,000.

The accounting transaction may be equally accurate in both cases.

However, the operational performance is completely different.

That is why the organization must associate the cost of resources with the same project structure it uses to measure progress.

Otherwise management can see money.

And management can see progress.

But it cannot reliably explain the relationship between them.

That is not Cost Control.

That is two reports.

When Quantity, Production Rate and Cost Align

The most powerful condition occurs when management can continuously compare:

Quantity

How much work have we actually achieved?

Production rate

How efficiently are we producing that quantity over time?

Cost

How much resource expenditure did it take to achieve it?

When those three remain aligned with the baseline, the project is operating close to its planned economic model.

When one starts diverging, management receives an early warning.

For example:

• Quantity behind + Cost on target

May indicate schedule/productivity problems.

• Quantity on target + Cost high

May indicate resource inefficiency.

• Quantity ahead + Cost proportionally ahead

May simply reflect accelerated execution.

• Quantity ahead + Cost below plan

May indicate improved productivity.

• Time passing + little quantity earned

Signals schedule deterioration.

This is why no one can interpret progress independently.

Instead, production and cost must explain it.

From Progress Reporting to a Continuous Reality Check

Traditional reporting tends to work periodically:

• Collect progress.
• Update P6.
• Collect actual costs.
• Wait for invoices.
• Close finance.
• Reconcile spreadsheets.
• Prepare a monthly report.
• Explain the variance.

By the time management sees the full picture, the event that created the variance may have happened weeks earlier.

By contrast, a project-centric ERP changes the sequence.

Site users continuously register:

• physical progress;
• labor transactions;
• machinery utilization;
• materials movements;
• production;
• subcontractor progress;
• inspections;
• certifications;
• and other operational events.

In turn, these transactions refer back to the same project structures.

The system can therefore continuously ask:

That is a genuine project reality check.

And This Is Also the Foundation for Reliable AI

AI makes this architecture even more important.

For example, imagine asking an enterprise AI agent:

If progress exists in P6,

materials in spreadsheets,

labor in payroll,

machinery in another system,

subcontractor progress in PDFs,

procurement in an ERP,

and actual financials in the general ledger,

AI must first attempt to infer the relationships among those datasets.

That is a probabilistic problem before anyone has even addressed the actual business question.

But if:

BoQ, WBS, Cost Codes, resources, progress and financial transactions are already deterministically associated,

AI operates from structured business context.

Now it can interrogate the project rather than reconstruct it.

That is the purpose of the ProjectVIEW ERP + ProjectVIEW AI architecture:

No one should ask AI to invent the relationships that the enterprise itself failed to establish.

So, How Complete Is a Project That Is “50% Complete”?

The correct answer is:

• It depends on what the 50% measures.

But Construction Management must go further.

If 50% represents verified physical accomplishment, management should then ask:

• What did we plan to have achieved by now?
• What quantity did we actually achieve?
• How much time did it take?
• What labor did we consume?
• How much machinery did we consume?
• What materials did we consume?
• How much subcontractor value did we consume?
• What was the actual cost?
• And what value did we earn?
• How much has the client certified?
• How much have we billed?
• And how much have we collected?

Only then does “50% complete” become management information rather than a number on a dashboard.

Frequently Asked Questions

What is actual progress in construction?

Actual progress is the measurable quantity or objectively verified percentage of project work genuinely completed at the reporting date. Teams should normally record it against the project scope represented by BoQ items, WBS activities or a controlled relationship between the two.

How should construction progress be measured?

Where possible, teams should measure construction progress through actual quantities completed—such as metres installed, cubic metres poured or tonnes erected. Where physical quantities alone are insufficient, teams can use predefined weighted milestones or Rules of Credit to determine progress objectively.

Is WBS percentage complete enough to control a construction project?

No.

WBS percentage complete is valuable for schedule management, but project control also requires comparison with physical quantities, resource consumption and cost.

A WBS progress percentage disconnected from labor, materials, machinery, subcontractors and financial transactions provides progress reporting, not comprehensive Construction Management.

What is the relationship between progress and Cost Control?

Progress establishes what work the team has achieved.

Cost Control determines whether the resources and cost consumed to achieve that work are consistent with the project budget.

Therefore, the organization should associate the actual cost of labor, machinery, materials, subcontractors and other resources with the same BoQ and/or WBS it uses to measure progress.

What is Earned Value in construction?

Earned Value is the budgeted value of the work actually completed.

It allows management to compare what the team planned, what it achieved and what that achieved work actually cost.

Oracle Primavera uses Performance Percent Complete to calculate Earned Value. Oracle Primavera P6 Earned Value definitions

What is the difference between physical progress and Earned Value?

Physical progress describes the amount of work completed.

Earned Value, by contrast, assigns the budgeted economic value of that completed work.

Therefore physical progress establishes accomplishment, while Earned Value helps management compare accomplishment with the project budget and actual cost.

Why can a project be 50% complete but already over budget?

Because physical progress and resource consumption may be diverging.

For example, a project may achieve 50% of its work after consuming 70% of its labor budget, 65% of its machinery budget and 60% of its total cost.

The percentage complete may be correct while the project’s economic performance is deteriorating.

How does labor productivity relate to construction progress?

Labor productivity measures the relationship between labor consumed and work produced.

For example:

metres installed / labor hour

or:

tonnes fabricated / labor hour

Tracking labor hours without relating them to measurable output shows consumption but not productivity.

Is material delivery considered construction progress?

Not necessarily.

A project may order, deliver, store, issue, fabricate, install and accept materials at different times.

Material arrival is important for logistics and commitments, but management should not automatically interpret it as physical construction progress.

Is subcontractor claimed progress the same as project progress?

No.

The main contractor should validate subcontractor claims against measurable work, inspection records, contract conditions, variations, previous certifications, deductions and retention before they become certified progress.

Why connect BoQ, WBS and Cost Codes?

Because they represent three different but interdependent dimensions of the same project:

BoQ — measurable/commercial scope

WBS — execution and time

Cost Codes — economic classification

Connecting them allows management to analyze physical progress, resource exploitation and financial cost against the same project reality.

For additional background on this architecture, see DANAOS’ discussion of WBS and project Cost Control. Why WBS Alone Is Not Enough for Project Cost Control

The Bottom Line

A project being “50% complete” is not enough information to manage it.

We need to know:

50% of what?

And then:

At what cost?

Using what resources?

Over what time?

Against what planned quantity and productivity?

Producing what earned value?

Because:

And when we continuously compare the value of the work achieved with the plan and with what it actually cost, we move from simply reporting a project to controlling it.

That is the difference between knowing that work is happening and knowing whether the project is performing.

Read more: 50% Complete According to Whom? Actual Construction Progress, Cost Control and Earned Value