Phase 2 — data and system assessment

What you will learn Four things to confirm before starting, and where you stall if you skip this phase.

If databases themselves are unfamiliar, start with What a database is.

The purpose of this phase

Analyse the existing data and systems and plan the integration.

In one sentence: confirm you can build it before you build it.

The most wasteful failure is this:

text

POC week 3: "you can't have that data"→ security approval is needed and takes two months→ or that system has no API→ or the data exists but the quality is unusable

Finding out while building means you already spent three weeks. Phase 2 turns those three weeks into three days.

Four activities

1. Map the data sources (API / DB / documents)

Write down where the data you need lives and in what form.

What you need	Where	Form	Access	Confirmed
Original invoices	accounting mailbox	PDF attachment	IMAP	○
Supplier master	ERP	DB table	needs a read account	△ requested
Account code rules	in someone's head	—	document via interview	✗
Past entry history	ERP	DB	same as above	△

Note the third row. Rules that live "in someone's head" are extremely common, and documenting them is itself an output of this phase.

2. Assess system integration options

Confirm how you can connect to each system.

Integration	Difficulty	What to check
There is an official API	low	auth method, rate limits
Direct DB read	medium	read-only account, schema-change risk
File exchange	medium	frequency, location, format stability
Screen automation only	high	breaks when the screen changes. Last resort

If it is the last row, reconsider. You can build it, but you cannot maintain it.

3. Evaluate data quality

Being able to access it does not mean you can use it.

text

Check:  □ how much is missing        (e.g. supplier code missing on 12%)  □ is the format consistent   (dates in three different formats)  □ are there duplicates       (the same supplier under 4 different names)  □ how far back does it go    (only two years)  □ how often it refreshes     (overnight batch, one day behind)

There are projects where "one day behind" is fatal. If data for real-time support is a day old, that project does not stand up. This is what you must find now.

4. Document governance and security requirements

Check	Why
May this data leave the organisation	personal data or trade secrets
Is approval needed, and whose	usually takes longer than expected
Must you keep logs	mandatory in regulated industries
Must it be air-gapped	if so, the whole architecture changes

Always ask how long approval takes. "About two weeks" and "it goes to the quarterly review board" produce completely different plans.

Output

System architecture & data flow diagram

One picture is enough. Something like this:

graph TD
  A["Accounting mailbox<br/>PDF attachments"] --> B["Read the document"]
  C["ERP supplier master<br/>read-only account"] --> B
  D["Account code rules<br/>documented"] --> B
  B --> E["Produce a draft entry"]
  E --> F{"Over the approval threshold?"}
  F -->|"yes"| G["Human approval"]
  F -->|"no"| H["Auto-enter into ERP"]
  G --> H

The picture must show where human approval sits. That is the start of guardrail design.

Gate — to move on

Have you confirmed you can actually access the data you need?

The standard for "confirmed" is you actually pulled it once. Not "it looks possible."

text

✗ "They say the ERP has an API"✓ "I got a read account and actually queried 10 supplier records"

Common mistakes in this phase

Judging from documentation alone

"It's in the API docs, so it'll work" → in reality the endpoint is disabled, the permissions differ, or the response does not match the docs. Actually calling it once takes 30 minutes.

Deferring security approval

The most common cause of schedule slip. Technical review takes days; approval takes weeks. File the approval request on the day Phase 2 starts. It runs in parallel while you do the other checks.

Eyeballing data quality

Looking at ten records and saying "seems fine" is not enough. Count missing rate, format variants, and duplicates across the whole set. A few lines of query.

Check yourself

1. What is the standard for "confirmed we can access the data"?

Answer

You actually pulled it once. "They say there's an API" is not confirmation; "I got a read account and queried 10 records" is.

2. Why does "overnight batch, one day behind" matter?

Answer

Because it changes whether the project stands up at all. Data for real-time customer support that is a day old makes the project impossible. This has to be found before building.

3. Why file the security approval on day one of Phase 2?

Answer

Because approval takes far longer than technical review. Technical checks take days, approval takes weeks, and it is the most common cause of schedule slip. Filing first lets it run in parallel with everything else.

Before building, check the legal requirements once → Regulation and compliance