Do these Product Realization Flowcharts make sense?

[Madfox]

I'm very confused...
a) customer places order..
b) inventory attempts (?) to fill the order (?)
c) was order completed (why take order if not completed?)

No:
a1) allocation specialist (?) allocates product...

Yes:
a1) simple...how to ship


Do you mean you have the inventory available to ship?
(I would hope the order wasn't taken unless sales knew availability of stock.)

The first decision point should be at IN001P, IMNSHO.

The Madfox

(P.S., I think your flowcharts mixes info with material. I recommend material being fat lines, and info being skinny.)

 

[Ashley Cardin]

I'm very confused...
a) customer places order..
b) inventory attempts (?) to fill the order (?)
c) was order completed (why take order if not completed?)

No:
a1) allocation specialist (?) allocates product...

Yes:
a1) simple...how to ship

Hi Madfox,
Thanks for your thoughts. I've supplied some responses addressing things on which you commented.

b) I state that Inventory "attempts" to fill the order because they may not be able to do so from the stock available to them.
c) I have changed this to say "Was the order filled completely?". What I'm asking is whether we had all of the product required for this order.

a1) Allocation Specialist is the job title of the person that actually goes through the product that is coming in from Receiving and determines whether it is needed for an order or whether it can go to Inventory as stock.

Do you mean you have the inventory available to ship?
(I would hope the order wasn't taken unless sales knew availability of stock.)

Sales is able to check the amount of stock for an item at any time from their workstations but wouldn't refuse an order because we don't have the product at this time. They will just let the customer know the status of the product and let them decide if they want to wait or not.

The first decision point should be at IN001P, IMNSHO.

What decision are you suggesting?

 

[AndyN]

Ashley:

A great place to start - the 'KISS' principle!

Many of the comments here are useful and I'd like to offer that "decision diamonds" are not helpful to management. Businesses don't, in general terms, make binary 'Yes/No' decisions. Often when a customer wants something the answer is, "yes, but" The decision isn't binary!

Your charts are a great place to start and have the 'real' process evaluated against then to see what's really happening. You should see the wasted effort when little piles of work start to add up because somethig's not correct with the input.........or similar.

Take purchase requisitions, for example. How many are processed 'right first time' and end up as a P.O? I'm willing to bet that because vital info is missing from the req., the buyers put them in a pile and wait until they can get around to calling the person.......sometimes days after. That's not a binary 'Yes/No' situation - that's 'waste'.

Also, how much time is wasted sending out three quotes to suppliers, reviewing responses and then placing orders? Unless you are lucky (make that very lucky) your organization has all kinds of opportunities to improve their processes that your charts could be used to help with.

But you've gotta get your management to look at them and see how, not by asking us.........(only)

Andy

 

[Jim Wynne]

Many of the comments here are useful and I'd like to offer that "decision diamonds" are not helpful to management. Businesses don't, in general terms, make binary 'Yes/No' decisions. Often when a customer wants something the answer is, "yes, but" The decision isn't binary!

So because decision boxes "are not helpful to management," they're not helpful? No one is suggesting that complex decisions should be crammed into a confined space. Nonetheless, nearly all processes sooner or later come to a point where branching occurs, and the rationale behind deciding which branch is appropriate (or which branches are permissible) must be expressed. It's called "process control."

Take purchase requisitions, for example. How many are processed 'right first time' and end up as a P.O? I'm willing to bet that because vital info is missing from the req., the buyers put them in a pile and wait until they can get around to calling the person.......sometimes days after. That's not a binary 'Yes/No' situation - that's 'waste'.

You seem to misunderstand the need for branching to be depicted. If, at some stage in the process, it's possible to go two or more different ways, what do you suggest? One box that says, "Do whatever you want, because it's not important"? Or would you rather have a process design that anticipates and controls branching?

 

[AndyN]

Well, Jim, I'm not sure what this reply is about.

Sure, a process can 'split' and the criteria should, indeed, be present for the person to make the choice. However, why you seem to think I'm not advocating that is beyond me. But then, you generally take a contrary position to my posts

I'm just saying that decisions are rarely made in a binary fashion and if you start getting into flow logic, the elegance of such diagramming becomes lost.

I prefer something along the lines of a 'value stream' map, rather than simply the logic behind a process, which is generally not questioned. It's whether the thing is efficient/effective which is lost from in pure logic map. That's why I offered this original poster that 'spin' on things.......

Further digestion of my post will reveal that I'm advocating other things than simply the graphical representations but that seems to have been missed. Would you care to comment on those aspects, too?

Andy

 

[Jim Wynne]

Sure, a process can 'split' and the criteria should, indeed, be present for the person to make the choice. However, why you seem to think I'm not advocating that is beyond me.

Your words:

I'd like to offer that "decision diamonds" are not helpful to management.

Now you're saying something different. And I also don't know what you mean by "management." Management of what? Or do you mean "top" management? In either case, I think I offered evidence that the basic statement is incorrect.

But then, you generally take a contrary position to my posts

Only when I disagree.

I'm just saying that decisions are rarely made in a binary fashion and if you start getting into flow logic, the elegance of such diagramming becomes lost.

Well, imo, you're wrong again, both in suggesting that the diamonds always call for binary decisions (they can be nested; there can be two or more paths) and that binary decisions are "rarely made." They're made all the time, especially in process design.

I prefer something along the lines of a 'value stream' map, rather than simply the logic behind a process, which is generally not questioned. It's whether the thing is efficient/effective which is lost from in pure logic map. That's why I offered this original poster that 'spin' on things.......

I don't want to turn this into a treatise on process design, but...
Value stream maps might have their place, but if they do, it's almost always after the basic outline of the process has been done. It's not an alternative, it's a different step. Process design is based on forming a hypothesis regarding the most efficacious flow, and PFDs are always subject to revision based on hypothesis testing. The fact that logic flow is "generally not questioned" is a major problem, and not something to gloss over. The fact is that the discipline of constructing a logical process flow chart ex post facto often results in confusion, and that confusion is almost always due to the fact that the process itself makes no sense. Which is why it should always be questioned. If you expect a PFD to be the last word on whether or not a process is efficient or effective, you're barking up the wrong tree. That's why there's that "C" in PDCA.