The course was Métodos 2 at UVG. The brief sounded simple until you started typing it into a model: pick a real process at a real company, measure it, simulate it, then defend an argument about where to spend money on it. Five of us walked into a pharmaceutical distributor's receiving dock with a stopwatch and a clipboard. Rafael O'Meany, Kenneth Monterroso, Juan Fernando Zuñiga, Víctor Massella, and me. The warehouse manager handed us the number that became the spine of the project: 900 boxes per truck, unloaded by 7 fleteros and processed by 4 bodegueros, total cycle 7.9 hours. That worked out to 113.92 boxes per hour and Q1.70 of direct labor per box. Those two numbers were the baseline. Everything we built afterward argued whether a different staffing or equipment mix moved them. ## What the receiving dock does A truck of pharmaceuticals lands at a planned hour. Seven fleteros (third-party loaders, paid per shift) move the cargo from the trailer to the receiving zone by hand. Then the in-house team takes over: four bodegueros run a chained pipeline of physical count and system entry, visual inspection for damage, internal labeling for traceability, and putaway by inventory rules and storage conditions. The supervisor is the audit layer. The whole thing is sequential, manual, and visual. No conveyor, no scanner integration, no labeling gun. For a pharmacy that's a real constraint: cold-chain product can't sit on a hot dock for two extra hours because the count was slow, and traceability can't be approximate. Whatever we proposed had to leave those controls intact. ## Measuring before modeling You can't model what you haven't measured, and you can't measure what doesn't have a defensible distribution behind it. The first week was a stopwatch week. We took 25 observations per variable task and ran them through Input Analyzer (the SIMIO companion that fits histograms to standard distributions and runs a chi-square goodness-of-fit) to get the right shape on each. What came out: - **Box labeling** fit a triangular: min 5 s, mode 9.9 s, max 12 s. - **Physical count** fit a scaled Beta: 0.46 + 0.54 · Beta(1.43, 0.873) min. - **Inventory putaway** fit a scaled Beta: 2 + 1 · Beta(0.719, 0.867) min. - **Constants from the manager**: truck check-in 5 min, dock prep 6 min, individual unload 15 s, box placement 40 s, visual inspection 0.5 min. One constraint we worked around honestly: no real unload was scheduled during our window, so load-to-zone times were captured by simulating the descent ourselves and validating against the manager's experience. We flagged that in the methods doc instead of pretending we had ideal field data. A caveated measurement that ships beats a perfect one that waits. Every entity, server, and resource you add is a commitment to validating that part of the model. We learned the discipline by feeling the cost of skipping it. ## The model in SIMIO SIMIO (a 3D discrete-event simulation platform: a model that ticks forward each time something happens, like a truck arriving at the dock or a bodeguero scanning a box) has a vocabulary worth naming. Servers are workstations where things get done. Entities are what flows through. Resources are what gets seized and released to gate the work. For our dock, boxes were entities, fleteros and bodegueros were resources, and the four post-unload stations were servers. I built the sprawling version first. Every observable step modeled as its own server, every actor as its own resource pool, full 3D layout. It compiled and ran. It also took a long time to debug, because every server we'd added was a server we now had to validate. Animation looked great. Confidence in the numbers was thin. So we cut. The version we defended dropped any process step that didn't move one of the two KPIs we'd committed to (cycle time per box, labor cost per box) and collapsed sub-steps inside count and putaway unless they had distinct time signatures. Inspection stayed because it is both a real bottleneck and a real compliance gate. The pruning made the model easier to validate against the manager's ground truth, which was the only validation we had. ## The brainstorm and the cut Seven ideas came out of the brainstorm: redistribute the team, mechanize labeling with handheld guns, cross-train workers across stages, fully automate the warehouse, hire a fletero, hire a labeler, buy lift equipment. Most were either trivially expensive (full automation, forklifts) or operationally vague (cross-train without specifying what changes hands). We boiled it to two scenarios worth simulating against the baseline. **Alternative 1: hire one extra bodeguero.** Adds a fifth person to the post-unload pipeline. The simulation pulled total cycle to 6.37 hours, throughput up to 141.29 boxes per hour. Pure speed win. But it raises daily labor cost from Q1,530 to Q1,720, so per-box cost moves up to Q1.91. You buy time at a permanent cost. **Alternative 2: equipment instead of headcount.** Four handheld labeling guns (Q240), three portable ladders for high-rack putaway (Q1,035), dock signage (Q55). Capex of about Q1,330, amortized at Q63 over the simulated horizon. Cycle went to 6.63 hours, throughput to 135.75 boxes per hour, per-box cost to Q1.77. Slower than Alt 1, but cost barely moved. ## Why we picked the slower one Alternative 1 was faster. Alternative 2 won the value-engineering matrix anyway. The decision rule was a weighted score on time-to-implement (0.2), cost (0.5), impact (0.3). Alt 1 scored 3.0, Alt 2 scored 4.0. Cost was the swing. The cleaner argument underneath the matrix: an extra hire is a recurring liability, equipment is a capex shock that pays back every shift the dock ever runs. The labeling guns also reduce error rates, and a relabel in pharma traceability is not a free operation. The ladders eliminate a category of physical strain and a category of damaged-product risk. None of that shows up in the cycle-time number. All of it shows up in the next year of operations. It was also the more honest answer to the brief. Methods 2, not Hiring 2. Hire-a-person was the lazy lever; equip-a-person was the leverage lever. The fastest scenario raised per-box cost. The second-fastest held it nearly flat and cut error rates at a step where errors are expensive to fix. The model existed so we could see that distinction with data instead of intuition. The Ishikawa-then-five-whys chain landed somewhere unexpected. The root we kept circling wasn't a process design failure. It was that nobody had budgeted for warehouse improvements because nobody had a reporting line that surfaced warehouse pain to the people who allocate budget. The cheapest fix above any equipment we proposed is a monthly throughput dashboard the dock supervisor sends up. Process improvement does not start at the process. ## What I took from it The most useful thing the project taught me was modeling discipline. Every entity, server, and resource you add is a commitment to validating that part of the model. The lazy version of a SIMIO build models everything you can see. The defended version models only what moves a KPI you committed to in writing, then validates each input against a fitted distribution or a manager who has watched the process for years. Smaller, well-validated models beat sprawling ones that look impressive in 3D. I built the sprawling version first. That instinct, the willingness to delete model surface area to make the rest trustworthy, is what showed up a year later when our team prepared for [WSC 2025](/projects/wsc-2025) at a much larger scale. The dock didn't need to be the whole warehouse. It needed to be the dock.