Should we draft in engineering software?

A question was posted on the AWI forums that was basically “should we draft in our engineering software?”

First let me say sorry up front- for the novel I’m about to send your way. This happens to be one of my favorite subjects… this turned into a kind of manifesto for me.

Before the novel, let’s get right to the point. The answer is: it depends (sound of audience disappointment).

I’m going to share the premises I bring to my opinion first, so that we can start from the same place.

The Goal, by Eli Goldratt
1. In any process that has a sequence of dependent steps, there is one AND ONLY ONE structural bottleneck. The step in the sequence that has the least capacity will control the output of the total system- or in other words, the total system’s maximum theoretical output is that of the bottleneck.
  1. My favorite example is this one- you have a millwork shop that has:
    1. Engineering who can program 50 cabinets in a day
    2. Machining center that can cut the parts for 50 cabinets in a day
    3. Bander that can edge band 100 cabinets in a day
    4. Assembly that can assembly 30 cabinets per day.
  2. In the above example, you will never produce more than 30 cabinets per day because the bottleneck dictates the output. It doesn’t matter that it was at the end- if engineering could only program 15 cabinets per day that would be the capacity.
  3. I’m using cabinets here just for an easy to understand measure of capacity- obviously in a job shop our capacity is in hours, not the output products since the number of products per hour will vary with complexity.
2. Any improvements to steps other than the bottleneck are illusions. They do not actually increase the capacity of the system.
  1. In the example above, if I go buy the world’s fastest edge bander, we will still never produce more than 30 cabinets. We will just stack parts up in front of assembly faster.
  2. There is a caveat to this- if we move labor around then investment in non-bottlenecks can make some sense because we could, for example, free up labor hours that the edge bander operator could go work in assembly.
3. The structural bottleneck should be protected at all costs. Every minute it is not working is a minute lost of production that can never be made up.
4. If the assembly line is doing things that other stations could do, then that’s just purely lost capacity.
5. My favorite example of this is light valence- in many shops their edge bander cannot band a 2″ wide piece of light valence, so they cut it 4-1/8″ wide, run it through the bander twice, then make their assembly team stop building and cut it apart.
  1. Because the bander has much more capacity than assembly in our example, asking the edge banding operator to do “extra” work and cut the light valence apart will not reduce the overall capacity.
  2. Having the assembly area no longer have to do that work will increase the overall capacity.
6. The goal of our millwork shops (unless you happen to be non-profit) is to make money. Everything is else is secondary. The goal is not the world’s most optimized g-code, the goal is not the world’s best yield, the goal is not 100% perfect engineering. The goal is to make money, and counter-intuitively sometimes that requires intentional choices to be less than perfect.
Michael Porter
1. Every company has a position in the market- a particular set of customers they serve, a niche they compete in, or something that is the reason for their competitive advantage.
2. There are pretty much only 2 positions you can take that give you an advantage over your competitors- lowest cost provider or to differentiate.
  1. Lowest cost is a position that can make money but is hard to keep- you become lowest cost by being on the bleeding edge of machinery and best practices. There exists a theoretical “efficiency frontier” – the most efficient you can become given current technology. Competing in this way requires constant investment to stay on that frontier- your competitors can buy the same machines you have and adopt the same best practices.
  2. Differentiation is the way to lasting competitive advantage- you have something different about your business that causes customers to be willing to pay a premium for your product. This can be differentiation based on product line, customers served, geographical differentiation, etc.
    1. I’ll provide examples from my last two employers:
      1. Wilkie-Sanderson’s position is “On Time Every Time”. This is what they are the best at. They are reasonably efficient, reasonably fast, reasonably all the other things a millwork shop needs to be (any large company will be reasonably good at these things or they wouldn’t still be around).
      2. Architectural Arts position is primarily being fast- “fastest guns in the west”. I have personally PM’d $400ks projects (about 75% die walls/paneling/monumental work and 25% cabinets) that go from contract to substantial completion in < 7 weeks. Nobody can tear through 4000 production hour project like Arts can. Arts is reasonably on time, reasonably efficient, reasonably all the other things a millwork shop needs to be.
    2. Each of these companies is reasonably good at everything- but Arts is not nearly as good at “on time” as WS and WS is not nearly as good at “really fast” as Arts. Each finds a different set of customers who are willing to pay extra for the thing that each is good at. Their overlap is honestly not that large.
Marc Sanderson (my boss, for transparency):
1. Strategy is a set of integrated activities that position a firm within an industry to earn superior returns over the long term.
2. Strategy is as much about the things you choose not to do as it is about the things you choose to do.
3. The entire organization needs to be aligned toward your strategy- every decision should be made in light of the strategy. Having a strategy makes hard questions easier.
  1. Should Wilkie-Sanderson go after hospital remodel work? No, this customer doesn’t care that much about on-time. They like to run every decision by all the doctors and nurses and delay everything. All processes within WS are structured to keep a project well-scheduled and on-time. WS will waste the extra cost required to operate that way on a customer who isn’t willing to pay anything for it.
  2. Should Architectural Arts bid a project that doesn’t deliver for 2 years? No, they don’t care that much about speed. All processes within AA are structured to handle fast jobs, so that’s the only way it knows how to operate. It will take that long term project and treat it just like the fast stuff, wasting the extra cost required to operate that way on a customer who isn’t willing to pay anything for it.
There are no silver bullets. If there were, we would just all make the same choice. Every decision we make is a trade-off of positive versus negative repercussions. I see so many companies that will reject any new idea or approach if they can think of even 1 negative repercussion. That is not how you evaluate a decision.

Having laid the groundwork I will share my opinion and reasoning for why I say “it depends”.

Many companies believe drafting or production engineering are their structural bottlenecks- incorrectly. Often they are overloading them with lumpy delivery (and remember you can overload any step by dumping enough work on it).
1. A PM has an entire hospital ready to release to “red-line correction” or production, but holds onto it for 3 weeks while waiting for an answer about a soffit on the 3rd floor.
2. This PM sees the positive sides of this choice to utilize large batch size:
  1. It is easier for the PM to manage- he doesn’t have to keep track of as many things. He only has to keep track of the status of “the entire project” or “the third floor” or “the west wing” or “Phase 1” versus potentially hundreds of rooms.
  2. The large batch size will likely get better yield- reducing the direct cost.
3. This PM is not in the right place on the org chart to see and understand the negative sides of this choice:
  1. Wasted capacity- possibly drafting/engineering were looking for work during this period. Possibly the shop didn’t have enough work (we all know work expands like a gas to fill whatever space is available, so they may not have run out but simply worked slower).
4. In this scenario it isn’t engineering that is the bottleneck- it is project management. The company only believes it is engineering because you can’t SEE PM backlog- it is intellectual and invisible. The Goal teaches that to identify a bottleneck you just go out on the shop floor and look at where the parts are stacked up. In order to do that you need to somehow make PM work visible. This is the purpose of Innergy’s bottleneck report.
Some companies REALLY do have a bottleneck in engineering.
1. Remember the light valence example above? You should PROTECT your bottleneck at all costs. Ask yourself- if you think your company has a bottleneck in engineering does your company act like it does?
2. Many companies I see have engineering departments that are drowning in rules. Every time something ever went wrong once, you added a new rule to make sure it never happens again. In some cases you’ve traded avoiding the once in 5 years expensive error for less productivity all year. That is a false savings. Some real life examples I have experienced:
  1. A bunch of dimensions that the architect/GC/other trades won’t care about- “just in case” your shop wants them.
  2. Putting a grain direction callout on every single door. A single statement up front that “all doors are vertical grain” is good enough- maybe once every year or two you’ll have somebody make a mistake, but you’ve removed tons of effort. Note: if it can be automated then it changes the analysis, but I see company after company manually placing all these in CAD.
  3. Review steps- I’m all for an internal engineering review step, but putting in place a person who checks all programming? You’ve just guaranteed a new bottleneck… just make sure your engineers learn from their mistakes from the shop (a feedback cycle) and after a few painful weeks they will all be as good as the person you were having check everything. Work doesn’t go into production until the PM Oks it? Great, it will sit there for 5 days before they even look at it.
  4. I’d rather have a system that delivers 95% correct/usable results all the time than one which delivers 100% correct results in twice the time.

Still hanging out with me? So the things that go into “it depends” are the company’s position/strategy and where the bottleneck within the company lies.

I was the engineering manager at both AA and WS and made different choices for those different companies. For WS getting drawings in early is part of the strategy (sometimes even supplying shop drawings before the project has been awarded as part of the process of securing the project!). WS takes longer term work that has a definite end- so definite that the customer is willing to pay extra to assure it happens. Think an entertainment complex that has a major celebrity booked… it WILL open on that date. WS gets lines on paper and turns it in, then spends the next year doing internal mockups/engineering refinement to reduce the cost and work out the kinks.
AA gets work that needs to be done fast. AA is using engineering software up front because there ISN’T a later to figure anything out.

AA does $7m worth of work for customers who supply their own shop drawings- drafting and production engineering can be very different skill sets. There is a skill associated with reading someone else’s drawing and making determinations about what you can change for standardization/ease of production/cost reduction. At WS those are different people, and WS is not as good as AA at taking someone else’s drawing and going straight to production with it- the production engineers are very skilled at taking off the WS drawings but do not have those skills I mentioned above. At AA an engineer does both drafting and programming- and therefore the production engineer has all those skills we talked about.

I argue that it’s hard to be good at more than one program. If you’re going to adopt the approach where an engineer does drafting and production, then you need to use your engineering software to draft, so that you can have engineers who are experts at one software versus being ok at two. If engineering really is your bottleneck, then the combined skill set approach can be a way to fight that bottleneck- at AA we could put 15 engineers on drafting or 15 engineers on production engineering depending on the needs of the organization that day. If it were split it would probably be more like 8 and 7, an obviously reduction in capacity.

You brought up the negative repercussions of the choice to draft in engineering software- I hope I’ve laid out some of the positive repercussions. If you like those positives, then the thing to do is to see what you can do to blunt the downsides. You mentioned “corrections” (adjusting drawings for red lines or field conditions) is slower…. Figure out how to fight that. Perhaps you’ve got some of the “dumb rules” in place that should be eliminated? Have your engineers tell you what takes the most time and see if you can eliminate it. My favorite way to fight “dumb rules” is to stop complying with them for a while and see who screams.

Some of those “dumb rules” will be about aesthetics- “we need the best drawings”. But going back to my premise, we are here to make money… the goal of the organization isn’t “the best drawings”. We need drawings that are exactly good enough to get approved by the customer, get through production with minimal problems, and get installed with minimal problems. That is it. It is very hard to hit that target exactly on the nose, so we should aim for a little better than that. If we’ve got a system that can automatically draw a box around adjustable shelves, but we do it manually because the automatic system draws at a different line weight than we’d prefer? You’re trading off productivity for something that matters. No customer will stop using you because your line weight of your adjustable shelf annotations doesn’t match the wall.

Consider outsourcing drafting if it makes sense with your company’s strategy. It has negative repercussions, of course, but those can be worked around. Compare them with the positive repercussions of faster throughput and more money in the bank.

Another of those “dumb rules” will be about yield- we have to get a certain yield no matter how long it takes, and if anybody in the shop can think that maybe it would save a ¼ sheet to move this over there/etc then back it goes to engineering. This is stupid. You’re increasing yield but causing people stand around with nothing to do, and putting more work back into a bottleneck. “Good enough” has to work. PS the computer literally ran tens of thousands of patterns and found the best one, you looking at something for 30 seconds and thinking this one change will not have any other effects is naïve. And if your engineers are wasting time manually nesting then that’s an even worse version of the same problem.

I also see this type of thinking regarding g-code- engineers hand-writing g-code or using less automated tools because the program will run 30 seconds faster. The goal is to make money, not make the world’s most optimized g-code. In the time you spend doing that I could program out tens or hundreds of sheets using a more automated tool.

I have a saying regarding the above concerns- your shop may end up with a better yield % or utilization %, but my bank takes deposits in dollars, not percents. We can do things that lower some measure of efficiency but make us more money… and laugh all the way to the bank.

TLDR version:
1. Figure out if engineering is really a bottleneck, if not move your attention to earlier steps and level out the work going into production.
2. Figure out how engineering needs to be structured to align with your company’s strategy/position. This will have a direct impact on the decision to draft in engineering software.
3. If it is a bottleneck, PROTECT it at all costs. Everything else that doesn’t conflict with strategy is negotiable. Literally everything.
4. Protecting it means assuring quality going in (never have a bottleneck working on something that can’t be used!) and adjusting processes to take work out of the bottleneck. This will again have a direct impact on the decision to draft in engineering software.