Input to a process

I was really happy to see the questions below put forth by one of my collegues. Putting it here because this is something I have been tossing about in my head for sometime now.

Hi,
For the past one year, we all are stuck doing process mapping and SIPOC
being the buzzword. I still have certain basic doubts related to SIPOC &
process mapping. I present here a very few but basic questions related to
process mapping & SIPOC, which immediately come to my mind.

1-Does
the input to a process necessarily be a document?
2-Whether all the inputs
utilized in the process, no matter at what stage, be included as “I” in SIPOC?
3-Whether the trigger of the process included in the documentation of the
process? (I am referring trigger to as the event initiating the process.
4-Is it necessary that trigger will qualify as the input? If so, then is it
not advisable to classify the triggering input from the rest of the inputs?

Looking forward towards collective enlightenment....
Regards,
XXXXXXX

Now my answers to these are below:
Q1: Does the input to a process necessarily be a document?
I agree with XXXX's answer. NO it is not necessarily a document. But you would say, that's what we have been representing in most cases.
Now guys what we have to reflect upon is whether our process maps have just ended up being representation of Data/Information flow. I think there is nothing wrong in it. I track the whole issue to the roots of SIPOC. Coming out of the Six sigma tool kit, it bears the burden of being something invented to describe production environment.
When we apply it elsewhere that primarily processes data, the primary input to most processes we depict is data ( document containing data ) whether it is a PO or a Change Request or application form. All the inputs I can think of is data in some way or the other.

To sum up, let's agree on a simple thumb rule. An Input is something that is processed or worked upon. For a machine it is raw material. For a system it is data. For any human who carries out the process it is some document/information/material.

Q2: Whether all the inputs utilized in the process, no matter at what stage, be included as “I” in SIPOC?
I do not entirely agree with the answer below(No : u cannot include intermediates inputs in SIPOC. SIPOC should always have inputs at the begining and outputs at the end of the process. If you are getting intermediate inputs and outputs then the process is not yet eligible for SIPOC. Intermediate inputs and outputs is an indication that you need to drill down the process further.). Because that would mean, SIPOC can be used to represent only atomic processes. Yes, if you break down the process to a certain level there can be only arrows going in from the left and coming out of the right (referring to the classical diagrammatic representation of SIPOC). But at this level the process maps would lose its meaning as you would not really be able to show the flows.

A process is not a machine that works upon whatever (raw material) comes in through the entry point. We have to allow intermediate inputs. I am again referring to the fundamental rule I put down above. At whatever stage it enters, it should be worked upon/processed and for that particular process it is an input.

I guess a case of confusion can occur if we start confusing a trigger with an input. Because a trigger is something that necessarily comes at the start of the process but not an input. And again let me be clear that there would be events in the course of a process that would act as triggers to other processes/sub-processes. And in turn may pass on inputs to these.

Q3: Whether the trigger of the process included in the documentation of the process? (I am referring trigger to as the event initiating the process)
This has to do with the question "Is SIPOC enough?" While you can start thinking on it, let me point out two very pertinent issues. I assume we define a process as something that has a definite start and end. Then the trigger is something that defines the start point. Until we clearly note it down, our documentation of the process is not entirely meaningful. I would say you have guided someone to Alibaba's treasure cave without giving him the magic words. OR if you let me be a bit more scientific, I would invoke the familiar Newton's First law :)

Now the second important part that SIPOC misses out is the Metrics. You are not through with the process until you define measurements. You are probably giving a product without a section in the user manual that describes how to know when things are going wrong.

Q: Is it necessary that trigger will qualify as the input? If so, then is it not advisable to classify the triggering input from the rest of the inputs.
I agree that trigger is not an input. To explain further, I will borrow a word from the BPMN vocab. A trigger can be considered as an EVENT. So a process is started when something happens. For example if your process starts off with an approval, then the letter of approval could be the input but the receipt of the letter of the approval is the trigger. OR let me try my wits at a trickier situation. Let's say the process in question is a planned/periodic activity. You would say the the schedule triggers it and at the same time you would be tempted to put the schedule as input. But my golden rule comes to the rescue. I am not going to work upon the schedule/calendar, and hence it should not be treated as an input. So what would be the input. If it is a warranty/AMC check up, the documents (let's say the contract document) could be the input. If it is a maintenance process, PM checklist could be the input. If it is an inventory count, the inventory list could be the input.

So... any comments..thoughts..reactions???