So if you look back in the archives of this blog you might see I've done some work taking data from Value Stream Maps (VSM's) and using it to build QUEST models semi-automatically. With pretty much any simulation package, a user is presented with an interface that exposes pretty much every option imaginable. With VSM, a user only tacks on the data they have available. Some people get overwhelmed by too many dialog options at once. In essence, when you're building a VSM with the intent of using it for simulation, you're only sticking in the data you have, and ignoring all the other options you don't have information for, with a much simplified interface (the VSM software).
It's also important to note that there are two different world views for manufacturing simulation packages, really, that I've seen: resource-based, and process-based. In a resource-based world view, you see all your machines on a virtual floor with some labor objects, maybe. Parts or whatever you call them enter at a source and jump around machines and modeling elements corresponding to, for the most part, physical objects. A process-based view is different, in that you basically get a flow chart where each block usually represents a process or a decision or something. The part item arrives at a source, again, but now moves between processes in sequence through the flow chart. A process can require different resources, so that parts end up getting blocked like in real life. Essentially both world views contain the same information and provide the same outputs, but just go about getting the outputs in different ways.
I'll tell you right now that a VSM pretty much takes on a process-based world view, except that people usually name their process boxes after the resource where the process is done. So there's sort of an implicit definition there, saying that we're doing a process, and that this process requires a resource based on the name of the process.
You may or may not know about QUEST's world view, so I'll go over that quickly: it's a resource-based view, with a construct called a "process" that holds attributes on the process, like what labor resources it requires and what the cycle time is and all that. There is also a "part class" construct that holds some attributes, including the sequence of processes the part needs to be "completed". A machine in QUEST can be told what processes it's able to perform, so that when a part arrives at it, it decides what process to do on that part, and we can then route the part on to its next process (whatever machine that may be at).
So a few years ago a client presented us with a VSM they had created that detailed the process flow for a line they wanted to simulate. It contained some cycle times, but it was, otherwise, pretty much just a process sequence.
So I had to figure out, how can I take this information in an
eVSM file (which has an automatic export to Excel) and turn it into a QUEST model. It was pretty easy to just do a one-to-one build of processes in QUEST; one process for each process block in the VSM. But the missing component of data, then, was how to tie a process to one or more machines in a QUEST model?
To tie a VSM process to a QUEST machine resource, I simply had to add a tag onto a process with the ID of the machine to attach it to (a many processes to one machine relationship). So the actual SCL code to do this consisted of reading through the Workstation column in the Excel file, and for each unique value in that column, just build a machine with that name. Then read through every process (row) and create a process in QUEST with that name. Then, look at the Workstation column for that process row, and assign the process to that machine (the Workstation value can actually be a comma-delimited list to specify that multiple machines can handle the process).
The next challenge was process sequencing. I could have assumed that the Excel output from eVSM was in order of the process sequence, but that'd be pretty limiting to a simulation user. eVSM requires that you provide a tag shape to each process shape, and the tag value must be unique for each process. So, I required that the sequence be encoded through just specifying a process' next operation in the sequence (using that next operations' tag text) as a process attribute. Then, the SCL to build the QUEST model just has to set the process sequence for a part class to the sequence of operations in that Excel file. This way of creating the sequence also allowed me to look at each individual process, and find whatever processes were feeding into it. So if I found two or more processes that both output to a single process, that single process must be an assembly operation, and require a part from each of them before running the process.
That brings me to my next, and final data requirement: the part type. Like I said, QUEST likes to have a part class for each unique part type in a system (there are exceptions of course, but I won't get into them). Each part type (in the type of model we're building here) should then have a sequence of operations for the purpose of routing and process execution. So to specify the part type for a process, I just required there be a Product attribute on each process, and the SCL chunks through the data and identifies the sequence of operations and assembly points and all that automatically.
But, to close out, we really need three pieces of information to successfully build a (however basic) QUEST model: what are our part types, what are their process sequences, and where do those processes get done. And a VSM is perfectly adequate at providing that information. I meant to be a lot more succinct in my explanation of how the conversion works, but I'm not sure it's possible. I'll give it a shot again some other time.
