5 ms·

When we started our own parcel service in 2015 we thought that everything that is needed on the actual parcel is the unique ID of the parcel (generated by a sys

by dfox 2y ago

When we started our own parcel service in 2015 we thought that everything that is needed on the actual parcel is the unique ID of the parcel (generated by a system reminiscent of twitter's snowflake and intentionally printed with digits shuffled around as to increase the chance of the prefix being unique). Pretty quickly we found out that various operational concerns need additional data on the label, with routing info (for manual pre-sorting on the depots) and recipients phone number (the courier locates the parcel in the trunk by that) being pretty important. Also, cool design of the label is one thing, but on both laser and thermal printers the resolution repeatability is much better in the direction perpendicular to the paper travel, so you do not want to do cute design things with vertical barcodes. And you want to have a huge margin below the barcode if it is aligned to the bottom of the label as some printers will occasionally get misaligned and part of the barcode will get on the next label… and the imaging scanners in Zebra terminals will happily read half a milimetre high code-128 barcode instead of the correct one on the bottom of the label.

inopinatus 2y ago
This isn’t a minor detail. As with stored-value cards vs credit cards, the location of the master record(s) has far-reaching consequences for dependant business processes. Any field activity depending on on-demand access to a centralised API contains the seeds of its own failure.
- dfox 2y ago
  The availability of centralized API was not the issue. The issue was that the operators were significantly more efficient when performing the process “by eye” than when supported by some kind of computerized system. For example the on-depot sorting process that we settled on was two-phase: first you sort the parcels either manually by routing codes on the labels or through automated sorting line with the current data and then in second phase the operator scans everything that is supposed to go out of the depot and in that process moves around the ~5% of parcels that got sorted incorrectly, which is incredibly more effective than doing that correctly in one pass.
  - inopinatus 2y ago
    > The availability of centralized API was not the issue. The issue was that the operators were significantly more efficient when performing the process “by eye” than when supported by some kind of computerized system. If you think these are different considerations, then you are splitting the wrong hairs. The processes landed on to resolve the conflict are not surprising, but also doesn’t sound like they addressed the underlying architectural conceit.
    - dfox 2y ago
      At a large enough scale you can do most of these processes by automation, except the actual courier delivery. And well, at least UPS has actual identified locations in their vans, so just going by location+barcode might be somewhat practical for them.
      - deleted 2y ago
        [deleted]
      - inopinatus 2y ago
        Beware of the line of operations research thinking that has latterly tanked Boeing’s engineering reputation, something the rest of us designing layered business processes can all learn from. Complexity is always best handled pushed down to the leaves of the tree. The ideal central body performs reporting and audit, not command and control. Although for some, I suppose the Boeing takeaway might be that the bottom line improved and no-one went to prison.

by dfox 2y ago

inopinatus 2y ago

This isn’t a minor detail. As with stored-value cards vs credit cards, the location of the master record(s) has far-reaching consequences for dependant business processes. Any field activity depending on on-demand access to a centralised API contains the seeds of its own failure.

dfox 2y ago
The availability of centralized API was not the issue. The issue was that the operators were significantly more efficient when performing the process “by eye” than when supported by some kind of computerized system. For example the on-depot sorting process that we settled on was two-phase: first you sort the parcels either manually by routing codes on the labels or through automated sorting line with the current data and then in second phase the operator scans everything that is supposed to go out of the depot and in that process moves around the ~5% of parcels that got sorted incorrectly, which is incredibly more effective than doing that correctly in one pass.
- inopinatus 2y ago
  > The availability of centralized API was not the issue. The issue was that the operators were significantly more efficient when performing the process “by eye” than when supported by some kind of computerized system. If you think these are different considerations, then you are splitting the wrong hairs. The processes landed on to resolve the conflict are not surprising, but also doesn’t sound like they addressed the underlying architectural conceit.
  - dfox 2y ago
    At a large enough scale you can do most of these processes by automation, except the actual courier delivery. And well, at least UPS has actual identified locations in their vans, so just going by location+barcode might be somewhat practical for them.
    - deleted 2y ago
      [deleted]
    - inopinatus 2y ago
      Beware of the line of operations research thinking that has latterly tanked Boeing’s engineering reputation, something the rest of us designing layered business processes can all learn from. Complexity is always best handled pushed down to the leaves of the tree. The ideal central body performs reporting and audit, not command and control. Although for some, I suppose the Boeing takeaway might be that the bottom line improved and no-one went to prison.