Skip to content
Use case 11 · Post-Sales / Project Delivery

Fire project procurement and delivery intelligence

A workflow that imports approved material demand, matches it to purchase orders, tracks deliveries and detects shortages — then shows which site milestone each shortage actually moves. Expediting decisions get made against consequences rather than against a spreadsheet.

Get the requirements document See the flow
Runs standaloneUploads and manual entryProject manager signs
Workflow 11 · demo runAwaiting sign-off

Procurement engineerApproved material needs, purchase orders and delivery dates sit in separate records.

  1. Import demandProcurement
    QueuedWorkingDoneSign-off
  2. Match purchase ordersAutomated
    QueuedWorkingDoneSign-off
  3. Track deliveriesProcurement
    QueuedWorkingDoneSign-off
  4. Detect shortagesAutomated
    QueuedWorkingDoneSign-off
  5. Show schedule impactProject manager
    QueuedWorkingDoneSign-off
Stopped for the project manager to sign
  • Who uses itProcurement engineer, project manager
  • Lifecycle stagePost-Sales / Project Delivery · also Operations
  • Buyer groupTrack C · Project Delivery
  • RequirementsBRD v0.1, sent as written
At a glance

What goes in, what comes out

Goes in
Released BOM
Purchase orders
Delivery dates
Procurement & Project IntelligenceFive steps · one approval gate Project manager signs
Comes out
Availability dashboard
Shortage log
Schedule impact
What it does

Procurement & Project Intelligence, step by step

Five steps, one decision point. The last step is a person, every time.

  1. 01
    Procurement

    Import demand

    Approved material requirements, from a released BOM or entered directly.

  2. 02
    Automated

    Match purchase orders

    Demand reconciled against what has actually been ordered.

  3. 03
    Procurement

    Track deliveries

    Promised and revised dates held against the order.

  4. 04
    Automated

    Detect shortages

    Gaps surfaced with the quantity and the date they bite.

    Does the shortage hit a milestone?

    Yes Expedite, with the impact shownNo Logged and monitored
  5. 05
    Project manager

    Show schedule impact

    The milestone affected, so expediting is a decision rather than a reflex.

  6. Output

    What lands at the end

    A material availability dashboard, a shortage log, a supplier action list and a schedule impact view tying deliveries to milestones.

Who’s involved

Procurement engineerProject managerSupplier

What you get

  • Availability dashboard
  • Shortage log
  • Schedule impact

In the wireframe

A buyer records a revised delivery date, links an alternate action, and shows the project manager the affected milestone.

Use case diagram

Who does what, and who signs

Automated steps prepare the evidence. People make the calls.

Swipe to see the whole diagram

Use case diagram: Procurement & Project Intelligence People: Procurement engineer, Project manager, Supplier. Steps: 1 Import demand; 2 Match purchase orders; 3 Track deliveries; 4 Detect shortages; 5 Show schedule impact. Project manager approves the final step. Procurement & Project Intelligence«workflow, built with DeX»«inputs»01 Import demand02 Match purchase orders03 Track deliveries04 Detect shortages05 Show schedule impactProcurement engineerSupplierProject manager«approves»«documents»Released BOM, …
Automated step Done by a person Approval gate Takes part Leads to
What changes

Why this costs you time today

Approved material needs, purchase orders and delivery dates sit in separate records. A shortage is invisible until it is urgent, and the link between a slipped delivery and a slipped milestone is reconstructed by hand.

Task
Today
With this workflow
Shortages
Invisible until urgent
Surfaced with the date they bite
A slipped delivery
Milestone impact rebuilt by hand
Linked to the affected milestone
The records
Separate spreadsheets
Demand, orders and deliveries reconciled
The line we do not cross

What this software will not do

Life-safety work. These limits are written into the requirements, not added as a disclaimer.

Specific to this workflow

It does not place orders, negotiate with suppliers or reschedule the programme. It makes the shortage and its consequence visible to the people who do.

It does not decide compliance

The software assembles evidence, retrieves source clauses and shows conflicts. It does not determine whether anything complies. A named engineer does.

It does not stand in for an authority

An approval recorded in the software never implies consent from an AHJ, Civil Defence, building control or a building surveyor.

Nothing leaves without a named reviewer

Every output carries who approved it. Anything unverified keeps a draft marker until someone signs it.

It does not do sealed engineering

Hydraulic network calculation, definitive sprinkler layout, sealed design, BIM geometry authoring and final cost estimates are all out of scope by design.

Your standards, not ours

NFPA, EN, BS, ISO, FM, UL, LPCB and Civil Defence appear in the requirements as examples. None is assumed to apply to your projects until you say so.

~1/10of traditional build time
~30%of traditional cost

That is a claim about how fast Colakin builds software with DeX, and it is supported by delivered projects. It is not a claim about what any of these fifteen workflows will save your business. The requirements deliberately leave that to a pilot, measured against your own baseline.

How an engagement runs

From a question to a pilot, in five steps

Nothing hidden behind a discovery call. Stop at step one and keep the document.

  1. 01

    You ask for the requirements document

    The full BRD for the workflow you care about, sent as written.

    Same day
  2. 02

    A ten-minute wireframe walkthrough

    A clickable prototype of that one workflow.

    10 minutes
  3. 03

    The Fire Fit Check

    Five questions: fit, hours lost, who approves spend, whether your documents can be shared, and timing.

    One call
  4. 04

    A scope built on your rules

    Your standards, your document formats, your approval gates.

    Within a week
  5. 05

    A pilot against your own baseline

    One workflow, your data, your engineers.

    Q1
Same buyer, same week

Also in Project Delivery

Each one stands alone. Take one first, then decide whether a second earns its place.

10 · Project Delivery

Technical Submittal Automation

Superseded certificates caught before the package goes out.

Indexed packageDocument registerSpecification response
Open the workflow

All fifteen workflows

Questions

Procurement & Project Intelligence: questions

How quickly does a project manager learn about a slipped delivery?
As soon as the revised date is recorded. The schedule impact view links it to the affected milestone, so the conversation starts with the consequence rather than the date.
Does it integrate with our ERP or purchasing system?
It works on imported demand and order data. Where an integration is worth building, it is scoped as part of the pilot rather than assumed.
Does it order anything?
No. Placing orders and negotiating with suppliers stay with your buyers. The workflow supports the decision, it does not make it.
Can it run across multiple projects?
Yes — multi-site delivery is the case it was specified for.
Next step

Ask for the Procurement & Project Intelligence requirements document

The business requirements document as written, including what it refuses to do. No brochure, no drip sequence.

  • The requirements document, usually the same working day
  • A ten-minute wireframe walkthrough with the people who specified it
  • No claimed percentage saving — your pilot measures it

Request the document

One working day. A person replies, not a sequence.

We use this to reply, nothing else. No list, no newsletter.