Tag Archives: systems

Spinning Wheels

From the Ask Tom mailbag –

Question:

In your Time Span workshop, you describe the friction between various departments, Ops-Sales-Customer Service-Accounting. You suggest this is a structural issue. In my company, we absolutely see this friction, but to me, it looks more like a personality conflict.

Response:
Most managerial issues look like a symptom, that’s why they are so difficult to resolve. The two most often cited problems (symptoms) are communication breakdowns and personality conflicts. You can have all the communication seminars you can afford, you can give everyone a personality test, the problems will remain.

The friction you describe between your departments is structural. Each department works from an internally focused agenda, with little consideration for other agendas in other departments. The exterior looks like a breakdown in communication. Not so.

Why is the agenda in each department internally focused? Simple. We, executive management, told them they had to be internally focused. We told each department they had to be efficient, profitable, no waste, no scrap, high utilization rates of internal resources, we told them they had to be internally focused.

In the heady days of growth, as these departments were emerging and developing, this internal focus was necessary, to gain those efficiencies, to make the output predictable. Absolutely normal. But now, that internal focus works against us. For the organization to move to the next level, those departments have to work together, support each other, cooperate, trade inside information, share planning, cross-train personnel.

You can spin your wheels with personality tests, but the fix is Integration. We have to integrate our systems and sub-systems together into a Whole System.

Flowcharting the System

“So, what does it take to create a system like that?” I asked. “To create a system that would notify for rejected parts along with lead times for replacement parts and alternate suppliers?”

Valerie was shaking her head. “I know our computer software pretty well and to program that functionality would be pretty expensive.”

I reached in my bag and pulled out a handful of 3×5 index cards. “Suppose I said that you were not allowed to modify your software and the only tool you could use were these 3×5 cards? Now build a system. Let’s start with how frequently it happens.”

“You’re right,” Valerie started. “It doesn’t happen that often. Our QC guy who certifies incoming parts, could send a card with the details to our purchasing person. Our purchasing person has access to lead times and alternate vendors. Purchasing gets their order quantities from sales orders, so they could run a reverse report to find out what orders would be impacted, that’s easy.”

“What else do we need to know to effectively respond?”

“We would need to get our sales people involved to find out what wiggle room we have on those orders. Since we are three weeks ahead of the game, there are all kinds of adjustments that can be made with ample notification.”

“If I asked to draw a picture of this on a piece of paper using circles, arrows and labels, could you do that?”

“You mean, like a flow chart?” Valerie asked.

“Like a flow chart.”

What a System Delivers

“Well, I thought our team did pretty well, given the circumstances,” Valerie continued to protest.

“Yes, they did,” I replied. “And those circumstances should never have existed. To come down to the wire and find you are missing 500 critical parts on an order should never have happened.”

Valerie shifted in her chair. “But stuff happens.”

“Yes, stuff happens all the time and that’s why your system should detect these conditions. When did you find out that your supplier had shipped 500 defective parts?”

Valerie looked to the left. “Three weeks ago.”

“What difference would it have made if your system had delivered a report three weeks ago that showed 500 rejected parts along with replacement lead time, a list of alternate parts vendors and their lead times, along with all orders pending that required that part?”

Valerie’s head was nodding. “We would have had three weeks to work on the problem instead of three days.”

System Detection

“But, we got the parts in and shipped the units. I thought we handled that quite well,” protested Valerie.

“You are right, your supervisor did a good job. That’s what supervisors do. But your work, as a manager, was not done,” I replied. “The job of the manager is to create the system. When you discovered you would be short of parts, it was your supervisors job to go find the parts, but it was your job to ask

  • Why didn’t our system anticipate this shortage?
  • Why didn’t our system detect this shortage as soon as the order was placed into our system?
  • Why didn’t our system spot our supplier’s inventory and indicate a shortfall in those parts?
  • Why didn’t our system have alternate vendors for those critical parts?
  • Why didn’t our system continually track alternate supplier inventories to find odd lots at aggressive pricing?

“The job of the manager is to create the systems, monitor the systems, improve the systems. It’s great that we have a supervisor who knows how to scramble. But I prefer a system that responds to our constantly changing circumstances. The role of the manager is to create those systems.”

Not a What, But a Who

Derrick located a copy of the org chart. “A little out of date,” he remarked.

“It’s time stamped only three weeks ago,” I said.

“Yeah, well, it’s still out of date.”

“So, if I think you have a system problem, where should I look on the org chart?” I asked.

“All these people are doing production, and the supervisors make sure production gets done. You have to be looking at our managers, they create our systems, monitor and improve our systems,” Derrick observed.

“Yes, and I see you have five manager positions. These are the roles accountable for your systems.”

“That’s why it’s a little out of date. One manager got promoted to Vice President and we figured he could still cover his old position. This manager, here, got an offer from another company, and we decided that we might be able to do without for a while. And our controller wanted to move to the northern part of the state. And with the internet, she does her work from home.”

“Let me get this straight. You have five manager positions, monitoring your systems, yet only two out of five actually show up for work here?”

Predictability and Uncertainty

“I understand how we calculate profit, but what does that have to do with my organizational chart?” Derrick asked.

“You design a predictable profit into your price, but what is it that keeps your profit predictable when you actually deliver your product or service?” I replied.

Derrick was thinking. “It becomes predictable when we are able to do the same thing over and over, the same way, with the same methods, in the same amount of time, with the same amount of scrap.”

“And how do you make all that happen over and over?”

“Well, we have designed a system and we train everyone to work the system.”

“And so, if something is happening with the predictability of your profit, what’s wrong, where do you look?” I continued.

“Something has to be wrong with the system,” Derrick nodded.

“So, where do you look?” I insisted.

“We should try to find out what’s wrong with the system.”

“Remember, I said that your problem is seldom a what, almost always a who?

Derrick grinned. “So, that’s why you want to look at the org chart.”

Detail Thinking at Stratum IV

From the Ask Tom mailbag –

Question:
At what Strata levels do details disappear, if they do?

Response:
Strata levels, as elements of Elliott Jaques model, create a visual representation of the Level of Work. Your question appears to ask about the behavioral traits of person, completing a task assignment, specifically curious about attention-to-detail as the task is completed.

Strata levels are descriptive about specific behaviors only as they relate to effectiveness in the completion of task assignments. Details never disappear. Even in longer Time Span task assignments, the devil is always in the details.

This is still an interesting question and may lend insight in describing the Level of Work in each Stratum. My answers, in the form of questions?

Level of Work – Stratum I

What details exist that will impact decision making on the pace and quality of the work?

Level of Work – Stratum II
What details exist that will impact decision making on the coordination of multiple elements, materials, equipment, people in the completion of the work, on time, within spec?

Level of Work – Stratum III

What details exist that will impact decision making in the creation of a system, so that tasks assignments are completed with predictable, consistent results, every time?

Level of Work – Stratum IV
What details exist that will impact decision making in the integration of multiple systems and sub-systems?

You see, there was an exercise described by Peter Senge in the Fifth Discipline (Stratum IV-systems thinking) called the Beer Game. The set-up of the game creates a brewery (system), two-step distribution (system) and a retail store (system). Because these systems in the simulation were not integrated, the end result typically produces the construction of an entire second brewery system. The detail, the retail store put beer on sale for one week during the simulation. The construction of the second brewery occurs NOT from market demand, but from a series of backorders put through the system in a non-integrated attempt to cover the sell-out of beer during a one-week retail sale period.

Yes, the devil is in the details, even at Stratum IV.