This page runs a small TMS in your browser: one distribution centre, three countries, fourteen orders. Every lever below is named after the things the role owns — business rules, planning parameters, master data, workflows, country templates — and every change you make is re-planned live and written up as a change request. Built by Greg Nowak as a working answer to “why you?”.
Open the cockpit ↓Tonight’s outbound plan from the Aarhus DC. Change the configuration on the right and watch the network, the KPIs, the EDI traffic and the change log react. Try switching consolidation off, pulling the cut-off back to 14:00, or removing the dangerous-goods workflow — then decide which of those you’d approve in production.
The posting’s own words, and where you met each of them in the cockpit above.
The entire right-hand panel. Each control is one of those five objects, and each carries a consequence you could see within a second of flipping it.
Every change you made was logged as a CR and walked through draft → tested → deployed. Config without that trail is how a TMS becomes unmaintainable.
The DE and SE variants. The craft is knowing which local exceptions are law (keep them) and which are habit (retire them into the group template).
Being the vendor’s counterpart means arriving with a reproduced case, config ruled out, and a ticket the vendor can act on — a discipline I bring from years of sitting between operations and logistics-system vendors.
The interface monitor above speaks IFTMIN and IFTSTA for a reason. Orders in, statuses out, invoices matched against tariff master data — that flow is the bloodstream of any TMS.
The exceptions counter is the support queue. When you removed the ADR workflow, orders didn’t error — they silently stopped moving. Knowing that difference is the job.
I have configured and implemented logistics systems — the workflows, business rules, planning parameters and master data underneath them — and I’ve lived with my own configuration running in production. I have not worked in CarLo, and I’d rather say so on page one than in week two.
What this role is buying is mostly product-independent: the judgment to tell a configuration fix from a product defect, the discipline to push every change through a tested CR instead of a Friday hotfix, and the diplomacy to hold one group template together across countries that each believe they are the exception. That is what this page demonstrates — built without a single CarLo screen to copy from, from understanding what a TMS has to do.
The CarLo-specific layer — its screens, its object model, its quirks — is what Soloplan’s documentation, a TEST environment and a vendor hotline are for. Product knowledge is a fast download for someone who already speaks TMS; configuration judgment is not.
Inventory workflows, rules, planning parameters and templates as they actually are in CarLo — not as the wiki remembers them. Output: a config map with owners.
Group template vs. every country deviation, each tagged “law”, “contract” or “habit”. The third pile is where simplification lives.
Triage open change requests, set one intake path, and get the test-before-deploy loop running so the change log looks like the one above.
Standing vendor cadence, a clean escalation path, and the first defect-vs-config calls made together — so the partnership starts on evidence, not tickets.