Phillip R. Kennedy

Ask a founder how an order moves through the business and you get a sentence. Ask them to draw it and you get a meeting. Claude just added whiteboards. You describe the process in plain words and it draws the board: every step, grouped by team, with the hand-typed steps marked. I put together a 50-second walkthrough using a made-up 40-person distributor. One paragraph of description becomes a map. A box dragged around the office steps, plus one question, finds the jam: every order is typed in three times. One more sentence turns the fix into a 90-day plan with owners and dates. Three boards worth making in your own business: How one order, invoice or new customer moves, and where it waits. A retro after a rough software rollout, with the notes grouped by theme. A system switch, laid out as a timeline with owners and dates. How to get it: Whiteboards is in beta on every paid Claude plan. Team plans have it on already. On Enterprise, an admin switches it on under Organization settings, then Artifacts. Then ask Claude to put your process on a whiteboard. The tool draws the map. Deciding which step to fix first is still your call. The walkthrough, with prompts you can copy: claude.ai/artifact/6LTU1wfVi… ➕ Follow me (Phillip R. Kennedy @prokennedy ) for plain-English ways past a tech bottleneck.

The inventory valuation never matched what we had actually paid. We kept chasing it anyway. A purchase order went in with the wrong cost. It got posted that way when the goods arrived. Somebody changed the cost later and never carried the change through. Now a layer of inventory sat in the system at a price nobody had paid. So we made a pricing adjustment to bring it back in line. And the next one popped up somewhere else. I have decades of stories like that. None of them end with it tying. The purchasing side didn't always feel the need to enter POs and costs correctly, or to post them correctly once the goods were received. Standard cost against actual, on FIFO, made it harder. Add real lot tracking and it was a mess. The quantities tied. We knew what was on the shelf. The valuation was the part that swung up and down when we calculated it at expected cost. And it wasn't a mystery. We could track down every transaction behind it. Getting them to settle was the problem, because people kept entering wrong information. It just seemed like whack-a-mole. You couldn't get it actually correct. People get so hung up on numbers tying to the penny. I understand why. A number that doesn't tie feels like a number you can't trust. But for real-time inventory valuation, even if it's directional, it's fine. Other numbers are different. Sales, invoice, and transaction dollars are easier to tie. When one of those is off, it's usually a formula error, and somebody should find it. There are limits to directional, too. I once worked with a company that believed in its margins until an ERP and strict processes showed they barely had any. Close enough was never going to be fine for that. I still haven't seen a clean way to make real-time valuation tie when lot tracking is in the mix. If you have one, I'd like to see it. Which number is your team chasing to the penny, and is it broken or just moving? ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned keeping the numbers honest between the order and the cash.

Everyone was on board with the new ERP. At first. We were on a burning platform. The old system had to go, and it had to go soon. Then it went live. Operations loved it. New efficiencies everywhere. Finance and accounting got a very different system. Same software, and problems they had never had before. It was like running two separate projects inside one. Admitting our successful ERP project was failing for some of us was the hard part. Here's what I do now. If it isn't going well, I scream as loudly as I can to anyone who will listen. Bad news counts as a status update. Nobody should carry an implementation on their back. If it's failing for part of the business, say so out loud, even after go-live. Especially after go-live. Who on your project is carrying something they should be screaming about?

Every acquisition came down to a question about item numbers. We mostly bought brands from larger companies. Each one arrived as data. Items, vendors, years of transactions, all set up for someone else's systems. Before anyone decided anything, we got access to the database and dumped it out. The master data. The transactions. Then we ran analytics on all of it. Then came the questions. Do we keep their item numbers, or map them to ones we already have? Do we keep their vendors as they are, or map them to ours? Every brand, every time. Each answer reaches further than it looks. It changes what operations sees on the screen, what the EDI maps have to translate, and which reports still line up next quarter. We made those calls with everyone who would live with the answer looking at the same datasets. Not a summary of the data. The data. There isn't one right answer. Keeping their numbers is faster on day one. Mapping them to yours is cleaner a year later. We went brand by brand. We got really good at it. It's part of how the company went from $60 million to $350 million in six years without the back office growing to match. More on that Thursday. If I were looking at an acquisition now, I'd want one question answered before close. Who decides whether their item numbers survive, and when do they get to see the data? ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned about the technology decisions that come with growth.

When my son was four, he had a way with frustration I still envy. He got it out fast and loud. Then it was nothing more than an afterthought. When his favorite toy broke, he didn't dwell on it. He found something else to do. His focus lasted about thirty seconds at a time. But while it lasted, nothing could break it. Kids are natural Stoics in ways the rest of us can only hope to copy. I'm still working on the loud-then-done part. Grown-ups tend to skip the loud and keep the frustration. What are you still carrying from last week that a four-year-old would have yelled about and dropped?

Built From Scratch prokennedy.substack.com/p/bu…

Some of the best people in operations spend 80% of their day doing the same manual process over and over. Keying the order. Checking the item. Fixing the ship-to. Next. They're good at it, and it works, so no one goes back and fixes it. It just seems too large a problem to fix. When I automate that work, I'm not trying to get rid of them. I want to take them out of the process so they can manage by exception, which is what they'd rather do anyway. The person who has keyed the same order all year is the one who knows which order is strange. Give them only the strange ones, and they spend the day on the customer instead of the keyboard. The work that's left is the work that needed them in the first place. Who on your team is spending most of the day on work they could do in their sleep?

Every retail customer had its own rules for how an order should ship. None of them held still. How many items were in the order. What it weighed. What it totaled. Those decided how it went out the door. The routing guides were so complicated that it was almost impossible to comply with them, even with the logic built into the EDI maps. Items changed UPC codes with the style and the season. Ship-to codes changed every time a retailer opened a new distribution center. Keeping those codes matched to real addresses, and mapping the new ones as they showed up, was one of the trickiest things we did. For a long time, every one of those rules lived in the map. That meant every change waited on whoever could edit the map. A developer. The retailer changes a rule. Operations notices. Operations asks. The developer gets to it, somewhere between everything else on the list. Meanwhile the orders keep coming in under the old rule. Nobody in that chain is doing anything wrong. The rule just lives with the wrong person. So at one company, we built business-rule generators that anyone in operations could use, on the fly. The person who saw the rule change could put the new one in and keep going. No ticket. No waiting for the map. The result was boring in the best way. We made very few mistakes, so the system didn't mess up. We didn't have to stop and resolve problems very often. It didn't make the routing guides easy. Nothing did. Some of those guides I'm not sure anyone has ever fully complied with. What it changed was the cost of the next rule. A change that used to wait in line became part of somebody's afternoon. The check I'd run on any operation now is simple. Pick the last rule a customer changed. Who had to touch it before it was live, and how long did it wait? If the answer is a developer and a week, that's where I'd start. ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned keeping orders moving when the rules won't sit still.

Every building we ran shipped three different ways. Containers. Truckloads. And single units sent straight to a retailer's customer, each one labeled as if the retailer had shipped it. Very large items and very small ones under the same roof. The biggest building was 425,000 square feet. We didn't buy a warehouse system for that. We built one. Postgres on the back end. A custom front end. Wave picking, shipment integration, and transportation management in one system. Put-away, slotting, restocking, and replenishment. Inventory flowing to the ERP in real time so allocation could trust it. Tracking going back out to customers close to real time. And we never stopped building it. We developed it continuously while it ran in production. Written down, that last part sounds reckless. Living with it, it meant a problem on the floor could turn into a fix without waiting for a vendor's next release. What I took from those buildings shows up in most of my work now. In a good warehouse system, almost nothing important is left to memory. If inventory moves, the system knows. If an order stalls, the system knows. If a scan gets missed or something lands in the wrong location, a signal fires. Not because people are bad. Because people are human. That was the job, more than any feature. Shortening the distance between something drifting and someone knowing. So that's the question I start with now, on any warehouse system, bought or built. When a pallet ends up in the wrong place, how long until somebody knows? Minutes is one kind of business. "At the next cycle count" is a different one. I wouldn't tell most companies to build their own. Most don't ship three different ways out of every building, and a bought system with good signals beats a homegrown one without them. Building it ourselves was the right call for us. I'm less sure it would be the right call today, with what the bought systems can do now. The time-to-signal question holds either way. In your building, how long does a misplaced pallet stay misplaced? ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned building the systems behind the order.

"I didn't know how much we needed IT until we had IT!" The CEO said that while he grabbed me in a bear hug, on what I thought was a normal Tuesday morning. I'd been brought in to build IT from scratch. It's a compliment and a confession at once. The honest translation: "I couldn't see what it was costing us until it stopped." Before a company has IT, IT is whoever fixes the printer. The real cost is spread across everyone's day, a few minutes at a time, where nobody adds it up. Nothing I did to earn that hug was clever. Onboarding that worked the same way every time. One place to send a problem and get an answer. And hours sitting with people, watching their day, warts and all. That's where the real problems showed up, and where I made most of my allies. If your company has no one in that seat, who's adding up the few minutes?

"We spent $2 million on this. Why are my people still using Excel?" The CEO asked me that on day 3 of an ERP go-live. Nine months of planning had gone into it, including a warehouse system with every bell and whistle we could think of. On day 3, orders weren't flowing. Inventory was wrong. The warehouse team was back on spreadsheets. I had no good answer. I've written about that question before. I called it a lesson about building a Ferrari when the business needed a Honda, and that part holds up. We built for the people who would admire the system, not the people who had to ship an order with it on a Wednesday. I've turned the question over a lot since then, and I hear it differently now. The CEO saw the spreadsheets as the failure. So did I, that day. They looked like proof that people had given up on the new system. What I've learned since is that a spreadsheet like that is usually doing a job. Somebody opened Excel because the system couldn't tell them something they needed before the trucks left. What was really on the shelf. Which customer got the short stock. Some of it's in a system, some of it's out of the system, and some of it lives in one person's head. The spreadsheet is where the out-of-system part gets written down. Every column is a question the new system hadn't answered yet. If I were back in that room today, I'd ask for the spreadsheet before I said a word about it. Not to take it away. To read it. Who opens it first thing in the morning? What would they do if it disappeared at noon? That list is the real punch list for the go-live. It's more honest than the one the project team is working from, because the warehouse wrote it under pressure. Then I'd ask the question from my old post, the one I still like: what would we cut if we had to go live in two weeks? Usually most of the bells and whistles. Almost never the thing in column C. I'm still not sure what I should have said to that CEO on day 3. "Give us a few weeks" was true, and it would have sounded like an excuse. If your people are still in Excel after a go-live, it might be worth asking what they're using it for before asking why. On day 3, the most honest report in the building was the one IT didn't build. ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned from go-lives that didn't go to plan.

I once spent eight months building the perfect consulting website. Custom animations. Copy rewritten until it squeaked. Checked on a phone down to the pixel. A friend launched his in a weekend, on a $50 WordPress theme. He booked six clients before I'd even bought my domain. In fairness to me, my animations were very nice. Nobody hired me for them. His site told people what he did and how to reach him. Mine told people I'd been busy. What's your eight-month website?

Fax to No-Touch prokennedy.substack.com/p/fa…

We told every customer the same thing: if the order comes in before 2 pm Eastern, it ships the same day. The order that came in at 2:01, we still tried to ship the same day. We tried to get everything out. The cutoff was more for us than for the customer. When an order didn't ship, the first thing we checked was when it came in. Before 2, we'd broken our own promise and needed to find out why. After 2, we'd missed, but we were still inside the promise we'd made. We set the line ourselves, so we could be a little flexible with it. What we couldn't do was move it after the fact. One timestamp told us which kind of miss we had. What promise does your team hold itself to, and could one timestamp tell you whether you kept it?

I've tried to pin down the moment we knew our AI plan was working. I can't find one. A while back I wrote about a company whose AI policy was one word long: don't. We replaced the word with about a page, and teams started experimenting again. This is what came after the page. We put one AI plan across the whole company. Product, engineering, sales, customer success, and the executive team, all working from the same one. Then a handful of decisions, made once: • Everyone standardized on the same model family. • Accounts were shared, so skills and what we learned carried from one project to the next. • That built up into a company brain. • Each connected system got its own level of security, and people saw only the data they needed. • Proprietary data stayed out of the models unless it really had to go in. The last piece was a project method. Every function ran its AI projects the same way, and that is what sped up acceptance and use across the company. It was a go-slow-to-go-fast kind of strategy, and it worked extremely well. What I can't give you is the scene. No meeting where somebody stood up and said it was working. I've looked for one. What I remember is the setup. I'd rather tell you that than make up a better ending. And it wasn't free. A company running on one model family has made a bet on that family, and the bet gets reviewed, not assumed. If your AI rollout is a pile of separate experiments, you don't need more tools to fix it. Try one plan, one way of running projects, and a clear line on what data never goes in. ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned setting up AI inside real companies.

We staged everything we could before the new ERP went live. There was just too much to stage. Too many customers. Too many items. Too much history. We had a lot of it set up ahead of time. The customers, the items, the mapping that turns a retailer's electronic order into one our system could read. We knew we were still missing a lot of the data and a lot of the mapping. We just couldn't see which pieces until real orders hit them. At some point we had to rip the band-aid off and go, knowing it would be painful for a few months, and that once we got past it, it would be so much better. It went live during COVID. The consultants and implementation partners mostly didn't come on site. We did it over Zoom, which took some getting used to. Operations ran on a skeleton crew, because you can't ship product from a warehouse remotely. Then the first orders started coming in. An item that wasn't mapped. A ship-to location the system had never seen. A customer whose rule hadn't made it across. Each one stopped until somebody fixed it by hand, and then the next one came in. It was a ton of work. I don't think anyone doubted it would work. The doubt was not understanding how we were going to make it work. That's a fair doubt. The how wasn't a plan we could hand anyone. It showed up one order at a time. What helped most came later. We moved the mapping out of a developer's hands and into operations, so the person who saw the gap could fix it on the spot. A while after go-live, an order showed up with an item nobody had mapped. Someone in operations mapped it on the fly, and the orders kept moving. It wasn't a big deal. Same problem as those first weeks. In the first weeks, it was a ton of work. Later, it was a few minutes. If a go-live is on your calendar, the staging list matters. So does a second question: when the first thing you missed shows up, who fixes it, and how long do they wait for permission? ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned on the far side of a few go-lives.

Some of a company's order process is in a system, some of it's in Excel, and some of it's in Julie's head. Julie isn't a real person. Most order desks I've walked into have one anyway. She knows which customer always sends the wrong item number. She knows which ship-to code changed last spring. She fixes it before anyone notices, and that's why the process works. It's also why nobody can see it. The best look at an order process I know of is the week Julie takes vacation. Watch what slows down, who gets called, and what sits in a pile for her Monday back. That pile is the part of your process that lives in a person. It's usually the first part worth writing down. Nobody needs Julie to work less. She should get to take the week off without a pile waiting. When your Julie is out, what waits for her?

The Access database that ran the company's orders was called Poor Man's EDI. That was its actual name. The company had no IT department. Years earlier, a controller who fancied himself an IT person had built the systems himself, in Excel spreadsheets and Access databases, linked together. Poor Man's EDI took the electronic orders from retail customers, ran them through lookup tables, and turned them into a file the order management system could import. It had issues every day. It was crazy that it ever worked. It did work, until the company grew. More volume, and it started to fall over. Nobody could process that many orders by hand either. Then the controller left, and the CFO inherited all of it. The only outside help was an MSP, and they handled the network. So the CFO called in fractional help for the short term. That was me. My first move was easy to pick. Get rid of Poor Man's EDI as fast as possible. What surprised me was what was inside it. They'd been running on it for years. Every nuanced business rule was captured somewhere in that spaghetti of a database. Order processing. Item processing. Pricing anomalies. I walked in expecting a broken tool, and I found the company's rulebook, written in a form nobody else could read. There was no way to go through it and pull it all out. So we put the business on a new system and recreated the rules on the fly, as the orders showed us which ones we'd missed. If you're about to retire a homegrown system, that's the part worth knowing going in. The ugly thing you're replacing is probably the only place some of your rules are written down. You'll rediscover a few of them the hard way, so decide ahead of time who gets to fix them when they show up. The CFO never needed to understand the Access database. The decision was knowing it was time to call someone who did. The short-term help turned into a full-time job. IT in shape, the systems in shape, then a team built to run them. That was a fun one. What's your company's Poor Man's EDI? ➕ Follow me (Phillip R. Kennedy @prokennedy ) for what I've learned inheriting other people's systems.

The Scorecard Went to a Different Department prokennedy.substack.com/p/th…