The Elsmar Cove Wiki More Free Files The Elsmar Cove Forums Discussion Thread Index Post Attachments Listing Failure Modes Services and Solutions to Problems Elsmar cove Forums Main Page Elsmar Cove Home Page
Google
  Web Elsmar.com
*Please be aware that SOME RECENT forum threads may not yet be indexed by Google.

View Full Version : Identifying measurable processes: How not to lose the forest behind the trees?


Yarik
16th March 2009, 01:57 AM
Hello everyone!

I've just started to work on what I believe is one of the first steps in building a QMS: identification and description of the essential processes in our company that are going to fall into the QMS scope...

As far as I understand the process-based approach, one of the key ideas is to make sure that processes are measurable (or else it would make them hard to improve).

One of the first questions I've got would be easier to formulate using some examples. (NB: The examples are grossly simplified to keep the main concern in focus.)

Example #1:
Let's consider an organization that essentially just sells some widgets to its customers. For the purposes of this discussion, it does not matter whether those widgets are manufactured by the organization or are bought by organization somewhere for re-selling elsewhere.

As a very first step, we can define only one essential process (again, just for simplicity sake):
PROCESS: Order Fulfillment

OWNER: Chief Order Fulfiller

INPUTS: Customer's order (widget ID, quantity, delivery deadline, price, etc.).

OUTPUTS: A bunch of gadgets delivered to the customer.

ACTIVITIES: Taking customer's order. Materializing widgets. Delivering widgets.

MEASURABLES: Order fulfillment time (from receiving an order to delivery of ordered gadgets), costs incurred, profit earned

NB: I can think of a ton of other useful measurables, but I have to keep things simple. So I've included only those that are pertinent to the problem I have.
So far so good (that is, no questions so far :-).

Example #2:
Let's consider a slightly more complicated situation: the same organization, but now it has competition and has to win customers' tenders to get orders.

Now it seems to be natural to have at least two processes. First, the very same "Order Fulfillment" process defined in previous example. Second, the process aimed on winning customers' tenders:
PROCESS: Bidding

OWNER: Chief Bidder

INPUTS: Customer's request for proposal (RFP) (widget requirements, quantity, bid deadline).

OUTPUTS: Proposal (widget ID, quantity, price, delivery time, etc.)

ACTIVITIES: Taking customer's RFP. Preparing proposal. Submitting proposal.

MEASURABLES: RFP processing time (from receiving an RFP to submission of proposal), costs incurred, percentage of tenders won.

On the surface, two processes appear to be sufficient: each of them is well defined and measurable, each of them therefore could be systematically improved. However, what about the bigger picture? For example, what about such "macro" metrics as

RFP processing time + order fulfillment time
cost of bidding + cost of order fulfillment
Obviously, they are very important (at least for the organization itself).

So, here comes my question: What is the common practice of capturing these "macro" metrics in Example #2?

<RevisedSection>

I am inclined to define the third process (with those "macro" metrics as measurables), but I have some doubts.

For example, defining an additional process to capture those "macro" (or "cross-process") measurables seems to be very consistent (and I am a BIG fun of consistency as a major ingredient of comprehensibility), but is it practical to define an additional process just because there are some interesting measurables not covered by other processes?

This question and the subject of this thread were inspired by the exellent "horror story" published shared here at Cove (http://elsmar.com/Forums/showpost.php?p=172716&postcount=46 (http://elsmar.com/Forums/showpost.php?p=172716&postcount=46)) - an example of how an organization's right hand may have no idea what its left hand does and how terrible the consequences can be.

</RevisedSection>

Please, advise.

Thank you,
Yarik.

Coury Ferguson
16th March 2009, 04:20 PM
Any feedback and/or comments?

Yarik
16th March 2009, 05:01 PM
Any feedback and/or comments?

I've revised the end of my post to explain some of rationale behind the question. Maybe that would help to solicit some feedback. (I still hope that the question is not too stupid to get feedback. :rolleyes:)

Jennifer Kirley
16th March 2009, 06:08 PM
Of course this is not a stupid question. It's very important.

That said, it's a difficult question to answer because there is a good deal to it. But I will try.

Plan, Do, Check, Act. This is Deming's famed Continual Improvement model, but you could also use its basis to help understand your QMS and process structure.

For each critical process:

1) Plan: What is to be done?
a) What the customer wants
b) What we need to do to deliver
c) What we know we can do
d) What we are willing to do to meet what we can't do now
e) What's needed to get 1)e) done
f) What we will do, and how, to meet 1)d)
g) Our process: documented if needed, understood if that's all that's required.
h) Define your success metrics. Be careful to make them specific to what goes on in each process, and ensure that the person doing the process can achieve. In your example, I was not sure the success metric of accepted bid could succeed because the bidder cannot control the business cost aspects that go into the bidding. This includes labor costs, overhead, available equipment, etc.

2) Do: What goes on?
a) The execution phase does what has been defined in the process - written or not.
b) Collect data that has been defined as showing the process effectiveness. As in #1)h), the metrics need to show what people can control.

3) Check: evaluate the lessons.
a) What do the data tell us?
b) What is working and what is not?
c) How can we tell?
d) What is the value?
e) What needs to be changed?
f) What makes us believe 3)e) is correct?

4) Act
a) Implement the lessons decided from 3). Back to #1.
b) Do not choose more than can practically be achieved. Choose the most value added changes.

An overall understanding of your business systems' needs is required. This cumbersome looking process (it's not s bad as it may appear) is repeatable for every critical process involved to get your product or service from the point of concept to customer satisfaction.

I hope this helps!

Yarik
16th March 2009, 10:14 PM
...it's a difficult question to answer because there is a good deal to it. But I will try.


Thank you!!


h) Define your success metrics. Be careful to make them specific to what goes on in each process...


That's exactly what I am trying to do.

But does it mean that, whenever I see a useful "success metric" without obvious process to attach it to, I should define a process to which that metric belongs as a measure of that process' efficiency or effectiveness? Somehow it feels more like invention of an artificial process than discovery of a real one...

If "process-less success metrics" are okay, then how exactly do you usually handle them in a QMS?

For example, what if, instead of fabricating a process to "host" those pesky cross-process metrics, I would do something like this:
(1) Define an activity like "collect measurements A1 and A2 of process A, measurements B1 and B2 from process B, ... analyze them and, if some problem X is detected, do Y and Z to fix it". For example, if some improvement of process A appears to be correlated with some worsening of process B, ensure that the former is not winning at the expense of the latter, and that the overall company's business is not actually suffering from improvement of process A.

(2) Make this activity a part of some process... which brings the next (hopefully easier) question: Is there any commonly defined QMS process that "hosts" activities like the one described above? Could it be one of the processes under "management responsibility" umbrella (ISO 9001 section 5) or one of the processes under "monitoring, measurement and improvement" umbrella (ISO 9001 section 8)?
Somehow I like this second idea much more than the idea of process "fabrication", but being a novice in this whole QMS area, I would really appreciate some feedback on it.


h) Define your success metrics. Be careful to make them specific to what goes on in each process, and ensure that the person doing the process can achieve. In your example, I was not sure the success metric of accepted bid could succeed because the bidder cannot control the business cost aspects that go into the bidding. This includes labor costs, overhead, available equipment, etc.


Is this about the measurable that I called "cost" for Bidding process?

Well, what I meant was something like the cost of resources (labor, equipment, purchased products, whatsoever) consumend by the bidding process itself. To me it looks like an obvious ingredient for computing the bidding process' efficiency. And I would think that the value of this metric usually is very much controllable (at least in part) by those who are involved into the Bidding process.

Having said that... another question: does a metric have to be controllable? I mean, I always thought that it is activities of a process that should be controllable, whereas a proceess' metrics are just supposed to reflect degree of effectiveness and/or efficiency of those activities... But then again, I must admit that I still have a very vague understanding of what is meant by "control" in this corner of the Universe :o. Any reference to a good definition/explanation would be greatly appreciated!!


I hope this helps!


It certainly did, thank you a lot!

Best regards,
Yarik.