# Data readiness in two weeks — Radexus

> A self-assessment you can run on your own systems before you talk to anyone.

*Source: https://radexus.com/guides/data-readiness/*

---

[Guides](https://radexus.com/guides/)  /  For operators

# Data readiness in two weeks

A self-assessment you can run on your own systems before you talk to anyone.

- Written for: **For operators**
- Length: **10 pages**
- Reading time: **9 min**

In this guide
- [Check one: how many customers do you have?](#h-0)
- [Check two: does anything have a timestamp you trust?](#h-1)
- [Check three: what does the loss reason field actually contain?](#h-2)
- [Check four: who would approve a write?](#h-3)
- [Reading the result](#h-4)

[Download](https://radexus.com/downloads/radexus-data-readiness.txt)

What to check, in what order, and what each answer tells you about whether a build is worth starting.

You can do most of this yourself with exports and a spreadsheet, and it is worth doing before any vendor conversation, because it changes which conversation you are having.

## Check one: how many customers do you have?

Export the customer master from every system that holds one. Count the unique names. Then sort alphabetically and read a hundred rows. If you can see duplicates with your own eyes in a hundred rows, the true duplication rate is high, and entity resolution is the first piece of work regardless of what you thought you were buying.

## Check two: does anything have a timestamp you trust?

Pick a process with a start and an end, quote to order, enquiry to visit, ticket to close. Can you compute the elapsed time for the last two hundred instances without manual repair? If not, you cannot measure a cycle-time improvement, so do not agree to one as your metric.

Most of this can be done with exports and a spreadsheet, before any vendor conversation.

## Check three: what does the loss reason field actually contain?

Count the distribution. If one value dominates and it is mandatory, the field is noise and no analysis of why you lose is possible from it today. That is fixable, and fixing it takes a quarter of observation before it has value.

## Check four: who would approve a write?

Name the person, per system, who would be willing to approve software-proposed changes into it. If there is no such person, the deployment will terminate in an export nobody opens, and you should solve that politically before you solve it technically.

## Reading the result

-   Clean timestamps and resolvable entities: a build can start now.
-   Messy entities, good transactions: resolution first, expect ten to fourteen weeks.
-   No trustworthy timestamps anywhere: fix instrumentation first. A model will not rescue this.
-   No approver: solve the governance question first. Everything else is premature.

**Take it with you**

Full text, no form, no email capture. Print to PDF or download as plain text.

[Download text](https://radexus.com/downloads/radexus-data-readiness.txt)Print or save PDF

**Use this on us**

Every question in this guide is one we expect to answer. If we cannot, that is information you should act on.

[Start a discovery](https://radexus.com/start/)

[Back

### All guides

](https://radexus.com/guides/)[Next

### Write-back safety

](https://radexus.com/guides/write-back-safety/)