Weeks 4, 5 and 6 are one assignment, not three. In week 4 you gather data that does not exist yet. In week 5 you shape it into something a system will accept. In week 6 you turn it into a view that changes a decision. It is the same data all the way through, which is the point: most of what makes data work hard is what happened to it before anybody looked at it.
This is real. The output goes into the asset register that Corporate IT actually runs on, and the numbers in it end up in a budget.
The register already knows which devices exist and which one is which. That part was built by the team that implemented it, it covered about 93.5 percent of records on 21 August 2026, and it is a real result. Identity is one of seven field groups.
What is being added on top of it is warranty, cost and lifecycle, and it is being added because new things need it. An insurance valuation after an office move needs location and replacement value. A refresh budget needs an acquisition date and an expected end of life. Finance needs an acquisition cost to depreciate against. None of those questions could be asked of a register that only knew identity, and now they are being asked.
How to talk about this work, and it matters. You are adding a layer, not fixing a mistake. If you find yourself describing the register as incomplete or as a gap, stop and say it the other way round: identity is done, and the new requirement needs financial and lifecycle fields on top of it. You will be talking to the people who built this register. Arrive able to say what is being added and why.
These hold for all three weeks. Every one of them exists because somebody, somewhere, did the opposite.
Request the approved laptop serial-number extract from the asset-data custodian within the team. Record the dated handoff reference and row count, not the custodian's name. You are going to end the week with a warranty start and a warranty end against as many of those serials as you can find, and a straight answer about the ones you could not.
Who the custodian is. One person holds the laptop lists and approves what leaves them. They are named in the first session of the week, not on this page, because this site is public and no colleague's name goes on it. Ask in the session if you were not there.
What to ask them for. Serial number, make, model, type and status. Nothing else. No employee name, no email, no phone, no ID number. If the file you are handed has a column like that, say so and ask for it again without it. Your hand-in is checked for exactly this and it will stop on it.
One team output, with visible individual depth. Use anonymous intern codes. Each intern owns at least ten serial rows from source to outcome, reviews at least five rows owned by somebody else, writes one hypothesis with measured evidence and a limitation, and submits one collection artifact built only against the approved training sandbox. Real vendor portals are handled through a permitted export, an API, or a manual lookup, never the training scraper.
The tool is yours to pick. Python with BeautifulSoup or Scrapy is what the plan names as an example, and it is a good one. Node, PowerShell, Power Query, SQL or a notebook are all fine if they get the job done. What is checked is the same either way: did you bound the request, pace it, cache what you fetched, follow the pages, fail loudly when a field is missing, and write something structured out. If the vendor publishes an API and you use it instead of scraping, that is the better answer, not a shortcut.
Do this first and the rest of the week is easier. Skip it and your match rate will be bad for a reason you will not be able to see.
| Do this | Why |
|---|---|
| Uppercase every serial | Mixed case is the single most common reason a bulk match fails. |
| Strip spaces and any stray characters | A trailing space is invisible and it will not match. |
| Deduplicate | A serial that appears twice will come back twice and inflate every count you produce. |
| Group by model | Lookups are per vendor. Grouping tells you how many go down each route before you start. |
| Count what you started with, and write it down | Every number you report in week 6 is a fraction of this one. If you lose it, nothing later can be checked. |
Lenovo is the main laptop vendor, so that is the bulk of the work.
| Vendor | Route | What you get |
|---|---|---|
| Lenovo | Batch Warranty Lookup: paste or upload a list rather than typing serials one at a time. Read the batch size limit on the page and write it in your log, then split your list to fit it. | Warranty dates and status. Not cost. |
| Dell | Dell support, by service tag. Fewer machines, so one at a time is acceptable. | Warranty dates and entitlement level. |
| Anything else | Note the vendor and leave the row blank rather than guessing. | A miss, recorded as a miss. |
The public lookup gives you dates, not money. Acquisition cost sits on the reseller's invoice, not on the vendor's warranty page, which is why the reseller route is the one that unblocks Finance. You are collecting the half that is publicly available. Do not fill in a cost you inferred, and do not estimate one. An empty cell is a fact. A guessed cell is a lie that somebody will later budget against.
You will not find everything, and that is not a failure. Serials miss for reasons worth knowing:
Record which one you think it is where you can tell. A miss list with a reason against each row is the thing that gets the next batch found. A miss list that is just serials is a list somebody has to do again.
Week 4 produced data that is true. Week 5 produces data a system will accept, which is a different and less forgiving thing. The target is the import sheet for the hardware object types in the asset schema.
| Rule | What breaks without it |
|---|---|
| Serial numbers uppercase, no spaces, exactly as the vendor prints them | The match key fails and the row silently creates a duplicate object instead of updating one. |
| Dates in ISO format, YYYY-MM-DD | Date comparison in a query stops behaving, so every "expiring this quarter" answer is wrong. |
| Status from the fixed list only: In Stock, Deployed, In Repair, Lost, Stolen, Retired, Disposed | Free text means two people count the same fleet and get two answers. Retired means withdrawn and still held. Disposed means gone, with a disposal record. |
| One row per asset. Never one row per event | A second row for a repair is how a register forks into two versions of the same device. |
| Empty stays empty | "N/A", "unknown", "-" and "TBC" are four ways of writing the same nothing, and they all defeat a query looking for an empty field. |
Group your sheet the way the register groups its fields, because that is how completeness gets reported in week 6. Write the source and the refresh path in a comment row above each block, so the sheet explains itself to whoever opens it next.
The template stays in English because it goes into the sheet as it is. Its comment rows say where each block comes from and what keeps it true; that expected_eol is derived, so you do not type it (week 6); and that the ownership block holds codes only, never an employee name or an email address (rule 5).
You will not run the production import yourself, and you should not want to. What you produce is the sheet plus the evidence that it is safe to run:
Three views. Not a dashboard of everything you have: three views that each answer one question somebody is actually asking.
One bar per group: identity, ownership, lifecycle, financial, contractual, location, status. Never one average across all seven. A record holding a serial with no owner, no cost and no lifecycle date answers no management question, and a single average is exactly how that gets hidden. Label the consumer under each bar, so the person reading it knows who is waiting.
How many devices fall out of warranty in each of the next eight quarters. This is the view your week 4 and week 5 work makes possible, and it did not exist before. Show the misses as their own band, so nobody reads the chart as if it covered the whole fleet.
Devices reaching end of life by year. Laptops on a 3.8 year measured average, phones on 2 years. Say on the chart that these are measured averages and not an approved replacement policy, because somebody will otherwise quote your chart as if it were one.
The test for the whole week. Show it to somebody who works here and see whether they learn something they did not already know. A chart that confirms what everyone assumed is decoration. A chart that makes somebody say "is that right?" and go and look is the job.
Asking is not a failure state on this assignment. These four are worth interrupting somebody for, and none of them is something to work around quietly:
The habit this assignment is really teaching. Anybody can pull a list. What separates somebody who can be trusted with a register is that when they hand it over, they can say where every column came from, how fresh it is, what is missing, and who is waiting for it. Do that for three weeks and it stops being an effort.