ProcessModeling

A process involves zero or more persons and zero or more things. A typical process involves getting these elements close to each other in space, but there are certainly (nontypical?) exceptions. For the sake of simplicity, the first draft of a process model might deal only with the "typical" type of process. This is especially true if the model is to draw heavily on SpatialModeling tactics such as SpringEmbedding. I|'m not recommending this, merely suggesting it. If someone actually knows something about the subject, please do tell me I'm all wet and recommend whatever makes more sense.

If WikiWorld were to go forward with a process modeling project using SpatialModeling kludges, it might proceed along the following lines. A processes might be represented in a database as having a name, as might a person or a thing. An object class encompassing processes, persons and things (among possible other subclasses) might be apropos. Although persons and things possess a certain tangibility or concreteness that processes do not, they have a sense of locality, at least in the case of "typical" (localized) processes. I suggest trying a model which uses the process as an attractor for its associated tangible objects.

Let's consider some examples. I am using household processes as examples for a number of reasons:

They involve consumer goods, which are the stuff of another project I'm interested in, PubWan
The focus on consumable rather than capital goods might help avoid the complexities of capital financing. Perhaps we can avoid an early loss of innocence brought on by a need to line up capital financing sources.
They don't assume any professional knowledge (znanie) or knowhow (umetnost), so they make the early literature of WikiWorldProcessModeling accessible to most anyone.

Here are two examples of household processes:

Washing dishes using a dishwasher.
Replenishing the drying agent in a dishwasher.

These are two distinct but related household processes. In practice they might be combined into one process, but usually are done at different frequencies, so modeling them as distinct processes seems to make sense.

Here is how the process of using the dishwasher might be modeled:

1,process,person-using-dishwasher 2,person,person 3,thing,semi-clean-dishes 4,thing,dishwasher 5,thing,dishwasher-detergent 6,thing,clean-dishes

Although this is a household rather than a business process, it is certainly an economic process. Objects 3 and 5 are "inputs", 6 is an "output", and 4 is a "capital asset", which in a formal business context would be a "depreciable asset". Our present interest is in process modeling, not CashFlowModeling, so for our purposes our inputs and outputs serve as (graph-theoretic) connections to other processes, such as pre-washing dishes in a sink, or setting a table.

Here is our other example process:

7,process,person-feeding-dishwasher 2,person,person 4,thing,dishwasher 8,thing,drying-agent

The leftmost number is a key, so objects common to the other process get their numbers restated. Note that capital assets, like inputs and outputs, can be common to more than one process. These eight objects can be arranged in a graph:

{{0,1,1,1,1,1,0,0},{1,0,0,0,0,0,1,0},{1,0,0,0,0,0,0,0},{1,0,0,0,0,0,1,0},{1,0,0,0,0,0,0,0},{1,0,0,0,0,0,0,0},{0,1,0,1,0,0,0,1},{0,0,0,0,0,0,1,0}}

[1]

Wow. You use a different process modeling then what I am familiar with. Of course, I'm a software engineer, so my modeling is based on my design needs and what management finds acceptable as presentations.

Just a note... geocities does not allow for direct linking to graphics. Would be best to make a link to the where people could see your graph.

I would have modeled dish washing differently, as well.

Standard Cleaning utilizing Dish Washer

Presuming: Empty Dishwasher
Presuming: Dishes( Dirty )
Presuming: User - Actor( Person )
Presuming: no errors or interruptions

Actor( Person ) opens the dish washer door. (Dish washer: Signal: Door Open)
Actor( Person ) loads dishes.
Actor( Person ) closes dish washer door. (Dish washer: Signal: Door Closed)
Actor( Person ) sets clean settings on Dish washer. (Dish washer: Signal: Settings Changed)
Actor( Person ) starts dish washer. (Dish washer: Signal: Start)
Dish washer washes dishes. (Dish washer: State: Washing {Note: See Work Substates})
Dish washer done.
Actor( Person ) opens the dish washer door. (Dish washer: Signal: Door Open)
Actor( Person ) unloads dishes, putting them away in cabinet.
Actor( Person ) closes dish washer door. (Dish washer: Signal: Door Closed)

Process completed.

Notice that the key points I am concerned with is the interaction between the Actor and the dish washer system.

Notice that the actual washing is a simple state, that can be further broken down into the sub-states of the washing/cleaning process.

---StarPilot

Your brand of process modeling is TemporalModeling and mine is SpacialModeling. Neither gives the complete picture. A very crude attempt to integrate some aspects of both is my essay "[[|http://www.halfbakery.com/idea/city20that20never_20sleeps#1005711159 City that never sleeps]]".