Comments(0) Yup, we never stop inventing new stuff here, and to prove it, check out the latest new product: Fujitsu Unveils Laptop Made of Corn. What will we think of next? 
Also seen on inhabitat.com.
Comments(2) If you don’t have an HD TV yet, you are sure to have one soon. Somewhere I read 50% of households have a digital TV, and I suppose some large fraction of that will be HD. But here is the scam: eventually you are going to need an HDMI cable, and the electronics store knows that you are not going to think ahead. Funny thing: all the cables are so very expensive. Not anything like the TV, but often between $100 and $150 for a 3 to 6 foot piece of wire. If you are lucky, they may have a “discounted cable” for $85.
Why are they so expensive? There is no real reason. HDMI is a digital connection, and there is a certification standard. As long as the cable meets the standard, the picture should be exactly equivalent. If you look around, you can find an HDMI cable on the web for $6 to $8 with gold plated connectors and fully certified. These places have HDMI cables for “normal” prices:
What is going on? Simple psychology. Most consumers will forget to buy the cable, until they discover they need one, and it is 30 minutes to the opening kickoff of the superbowl. They know you are are going to focus on the main purchase: the 50 or so inches of gleaming glass and glow where you will shell out between $2K to $5K or more. “Would you like a cable with that?” they will say. What difference does $100 make in a purchase of this size? Who wants to take home a brand new TV, and not be able to turn it on to watch? Who wants to take home a brand new PlayStation or other high def DVD player, and then have to wait a week or more to be able to enjoy the full resolution? You are going to want the cable right then. The markup on these cable is in the 10x range if you buy from an electronics retailer.
I went (of course) to Fry’s to search for a better deal. In the TV department, they had the standard $85 cable on display. I looked they guy in the eye and pointed out that Fry’s is a discount store, and he said I could find a better deal in the electronic parts department. Over on the other side of the store, I found the rack where HDMI cables hang empty. After rummaging around on top of the overhead shelf, I found a package with a 6 foot cable for $25 that someone had probably stashed up there for possible recovery later. That was clearly the best deal I was going to get three days before Christmas.
The retailers know that they “have you” over the cable and that is why the prices are uniformly high. And, to be fair, none of them are going to sell more TV’s by lowering the prices of the cable. But it just plain bugs me that the price is so inflated.
Here is my recommendation: click on one of the links now (do it right now) and purchase an $8 cable and have it shipped to you the slowest, cheapest way. Eventually, probably in the next year, this is going to save you money. It might save you anywhere from $20 to $50. Either way, a $10 investment with a 2x to 5x return within a year is a good investment in anyone’s book. But the satisfaction of telling the saleman you don’t need the cable is priceless. Even if you don’t have an HD TV, and are not planning to get one in the next year. A you might be the guy (or gal) with a spare HDMI cable, 30 minutes before the superbowl game.
Links to similar articles: arstechnica, gizmodo, macrumors, searchwarp, cnet, playstation.
Comments(2) The BPMN specification includes a sample process to use as an example of how you would use BPMN to draw the process and how it would then be converted to BPEL. Bruce Silver has suggested that this be used as an example process to test interoperability between different process diagramming tools. One point in favor of this is that it is fairly well fleshed out and documented. Also, it is a real process that would be reasonable to use in real life.
As I set out to implement this process, it struck me how dramatically different the process would be drawn if you had an implementation engine that supported human activities directly. Many of the things which are broken out into seprate activities would be combined into a single activity. Even at the basic level, the model would be different, because you would be modeling the human activities, instead of the flow of data back and forth. The process as it is diagrammed was designed from the beginning with the idea of being implemented on a BPEL engine. The process model as it is drawn approached everything from the point of view of what would be possible with a BPEL engine.
The best way to explain this is to show what the process would look like if you were to implement it using a human facilitation style BPM engine, and that is what I will do below by applying the Methodology for Human Processes to the email voting scenario.
The first step is get a list of the actual human activities that appear in the process. To do this we fly up to the 40,000 foot level and look down, ignoring as much as possible the details that came into the process due to the orientation to be able to executed on BPEL. We start with the activities that have to be done by people, because they require human intelligence, and really can not be automated.
1. Choose the issues for this week. The scenario assumes that there is an open ended list of possible issues which are being continually added to. It is not possible to talk about all issues every week, so someone must pick the most important issues. It is not possible to automate the determination of what the most “important” issues are, so this task of picking 1 to 5 issues for discussion and voting this week must be done by a person. There may not be enough issues this week, or it may be a holiday week, or any number of other possible reasons not to discuss issues this week, so the issue manager must choose whether there are “Issues” or “No Issues” this week.
2. Discuss Issues. There is a period time within which people are allowed to discuss the issue, and that means having access to the issue descriptions, access to comments that others have made, and the ability to make comments on the issues. This is performed simultaneously by a large number of committee members.
3. Determine is Discussion is Over. The issue list manager is asked in this process to take a look at the results of the current discussion, and decide whether the discussion needs to continue or not. Since this is a decision that is not automatable, we have to have the issue manager do it. There are two choices: “Continue the Discussion” or “Finish the Discussion”.
4. Vote on the Resolutions to the Issues. Mainly just recording the results of the activity. In this step, we can make use of a parallel activity called a “Voting Node” to allow everyone to be informed about the vote, to collect their responses in a convenient way.
5. Remedy Voting. This is a human activity in the case that voting “fails”. Voting can fail when not enough people vote. The original BPEL oriented process had a number of steps, most automated, to handle this situation. When considering the human tasks, an analysis of the process leads to the conclusion that a large number of the possible paths are automated, but a few of the paths require a person to address the situation by either reducing the number of voters or reducing the number of options being voted on. The key here is that in those situations that a human must be brought in, what is important is that the person be notified that the voting has not worked, and be given a couple of options to remedy the situation. So for the purpose of modeling the human process and for making the decision of how to proceed, I have collapsed this to a single activity node for a person to perform. The automated aspects are ignored at this point.
Then we have human activities that are necessary because the technology is somewhat limited, and not completely automated, and so there are some tasks which people do manage and maintain the systems
6. Moderate the online discussion. Unfortunately, the discussion is not completely self moderating, and so someone must have special access to possibly delete spam and inappropriate messages, and to help people to keep the discussions going.
7. Hold or attend conference call. The discussion on the issues is not completely on-line discussion, but also conference calls are a way that people come to a common understanding of the issues and resolutions. Someone needs to set for the conference call and moderate while it is happening.
The above seven activities account for everything that is done by people in the process (if I considered everything correctly). There are only two roles in this process. The Issue Mgr is the person who is managing the issue process. This could be multiple people, but only one of them would act at a time. The other role is the Committee which is everyone who is involved in discussing and voting on issues. The committee members are responsible for Discussing Issues and Voting, while the Issue Mgr is responsible for all other activities in the process.
The email voting process actually consists of two processes: a singleton starter process which loops and starts an instance of the actual issue voting process every week. The issue voting process then has two subprocesses. Because we have only seven human activities, I decided to keep it simpler and not use the subprocesses, and to do everything in the two main processes, though this would have been a choice if you wanted to you could use subprocesses to group things differently.
In doing the analysis I became aware of a strange behavior of the original process as written. You could very easily be in the position of being asked to run multiple conference calls at the same time. Remember that issue handling process is started every week, which drops into a subprocess for decision handling and another for voting. Each of those subprocesses have logic for determining if there will be a conference call during that time period, and to trigger an activity for handling the conference call. The discussion subprocess may loop, potentially for multiple weeks. It is possible that you will have multiple instances running at a time, and if this is the case, each instance will prompt for a conference call. The issue manager might manually avoid having multiple instances running at the same time, by deciding not to discuss anything in the new process instance as it is started, but this rather begs the whole question of why there are the possibility of multiple issue resolutions processes in the first place; why not simply have the singleton starter process do all the work? Finally I settled on the idea that issues are grouped, and it makes sense to have the possibility of multiple issue groups being discussed and/or voted at the same time. The conference call on the other hand is scheduled every Thursday, and takes place regardless of the number of issue groups currently, and therefor should be associated with the singleton starter process, and not the instances of the issue voting process.
The starter process
There is a single instance of this process, which loops every week. There are timer delay nodes that cause things to happen at specified times. At 9am Monday morning, an instance of the issue list process is started. This is done with an “asynchronous” subprocess node; this is a node that starts a subprocess, but continues without waiting for that process to finish. The ability to start a subprocess and not wait for it is commonly available on human process engines, and is a standard part of the XPDL file format. This is one clear area where the capabilities of the engine will certainly effect how you draw the process. If you think about it, the purpose of this starter process is to create instances every week of the email voting process, but because in BPEL there is no operation for expressing this, the original process would “send the issue list” and the “receipt of the issue list” would cause the creation of the process. This is quite strange when you consider that the issue list itself is probably on a server that is already accessible by everyone, and does not need actually to be “sent” anywhere! The sending and receiving of the issue list is an artifact created just to get around the problem that BPEL does not have an operation to create a subprocess! This is also partially because BPEL is not modeling the work that people do, but only modeling the sending and receiving of data. OF course, it is possible to model the whole world in terms of sending and receiving bytes, but it is far clearer and easier to read a process diagram with a node that creates the subprocess directly.
Then, on Thursday at 9am there is an activity to hold a conference call. This is assigned to the Issue Manager. I embellished the process a little bit to also give that manager a choice of whether to conclude the working group or not. The original process had a branch node that checked something to see if working group was still active, but then someone would have had to have taken some action somewhere to indicate that the working group is completed. Drawing it this way ties both the human indication that the working group is finished together with the completion of the process. Every week, the conference call task will be concluded with the choice “Continue Working Group” which is no additional effort over simply saying that the conference call is done. But, when the time comes that the working group is no longer active, and there is no need to ever have another conference call or another issue vote, then simply choosing “Conclude Working Group” provides an easy to complete the process without using the administrator’s console.
The Issue Email Voting Process
This process starts two activities from the start. “Moderate Discussion” is designed to remain active the entire time the process is running. Most of the time the process will be in the Discuss Issues step or the Vote step, and so really this step allows a place where the issue manager can moderate both discussion and voting. I embellished it a little bit to add a “Terminate” option that would shut down the process before discussion or voting was finished.
The main process is the lower 5 activites. First the issue manager decides the issues to be discussed. Second, the issues are discussed by the committee. Then the issue manager decides if the issues have been discussed enough and completes that by either “Restart Discussion” or “Call for Vote”. If it is the latter, the committee is asked to vote. If the vote is not conclusive, then issue manager must Remedy Vote and where he will be able to reduce the number of voters or the number of resolutions to vote on, and to choose either to Terminate the process, go back to Discussion, or go back to Vote.
How does the “Vote” work? Here we cheat a little bit by using a capability of the engine that present the vote options to a number of people simultaneously. It gives the options of “Yes”, and “No” to all committee members. People choose one, and the process engine tallys the results. On the outbound arrows, you can specify how many votes, or what percentage of the votes, are necessary to consider the an option successful or not. As soon as the success criteria is met, the voting activity is concluded. There is also a built in timeout so that if a vote is not concluded in a period of time, then the activity can be concluded down a third arrow which leads to the Remedy Vote activity. I know this seems like cheating to pull something like this out of the hat, but I did not make up this process, voting steps are relatively common in the worplace, this is a real node type available in a number of human process engines. As much as anything else, this should make it obvious that the way you draw a process in BPMN is highly dependent upon the underlying technology that you are going to use to implement it. For the discussion node we also use a voting node, even though we are not voting, and again it ends with the built-in timeout mechanism.
How are people notified about what to discuss? How are they told what to vote on? When you assign a human level activity to a person or group of people, that activity automatically includes a notification mechanism that tells them what they are to do, and includes information about the specific case. Simply assigning the “Discussion” node to the Committee means that everyone in the committee is automatically told what it is they are to discuss at the time that the discussion is to start. Simply assigning the vote node to the Committe means that they will be notified what the voting options are at the time they are to vote, and their votes are automatically collected and tallied.
What about the nodes to send reminders? Again, this does not need to be explicitly modeled because every human activity automatically includes (a) notification, (b) information, (c) conclusion, (d) deadline, and (e) reminders. We just set up the discussion activity to have a reminder after 6 days. Similarly on the voting node, we have a reminder after 6 days. That reminder on the voting node can be considered a “warning” since if the vote has been concluded, then the reminder will not be set. The BPEL oriented process had to stop the voting, and then go back and restart the voting after the warning, but that is not necessary when the voting node can send reminders without stopping. Even the nodes for the issue manager can have warnings and reminders if the issue manager goes for a time without taking care of the task.
What is this Human Process good for? By showing the process, you see what everyone is expected to do. At each step in the process, a person is told that something must be accomplished, and given a set of choices. The diagram is oriented around what it is that people do, not what bytes are sent and receive. As such it is useful for explaining what will happen next in the process depending upon which choices are made. This is useful for training people, and it is useful to display the current running status of the process instance to people. But some will point out that it is not complete; it does not contain a representation of all the automated actions. This is true, but no process map is entirely complete. For example, the process variables are not displayed in either the BPEL oriented process, or the human oriented diagram.
What Does All This Mean?
The key point I am trying to make is:
above is a specific process modeled in BPMN, but the way that you model in BPMN depends upon the methodology you use, and the underlying technology that will support the process
There was a desire for BPMN to represent the Universal Lingua Franca of business processes. If you want a particular process, then just draw the diagram in the one true univeral BPMN way, and you will will be able to run that on any engine. But that only works if the engine you are using matches the capabilities you had in mind when you designed the process. A BPEL engine, for example, allows you to send and receive data, and so your model is always around sending and receiving of data, which is useful if that is what you want to do. But many people want to model what humans do in an organization, and modeling humans as sending and receiving data is quite uncomfortable.
BPMN is a great notation standard. Still, implicit in that BPMN diagram is a set of assumptions about the underlying engine that the process will run on. Perhaps more importantly, the diagram is designed to communicate a particular thing to a particular audience. If you want to communicate to people, you will draw the diagram one way, if youwant to communicate to software developers, you may find the need to draw the diagram a different way. BPMN was designed to be used in both these domains, and still offers a great service that at least we have a set of symbol which if used consistently will be readable by everyone.
Comments(1) With all the talk about “Human Facilitator Processes“; what actually does a real one look like? The best documented example of a human process is provided by the OMG known as the “Trouble Ticket” scenario. You will find at the following OMG site address:
http://www.omg.org/docs/bom/98-02-09.pdf
This is a process to allow a software company to handle a customer support issue. This issue might be handled by the customer support team directly. If not, it is forwarded to the QA team for validation/verification and possibly handling the issue there. If it is a real problem in the product, it is referred to the development team for a fix. Before the process is complete, there are steps to assure that the customer who reported the problem gets the final resolution.
This is not a toy process like most of the example processes used in the various specifications. It is a real process that provides a complete important business function. While it is a simple process performed by people, it is important to support this with a process system because a business can not afford to lose track of customer issues.
If we follow the methodology for a human process, we start by identifying all the of the activities that are performed at points in the process. Please use the above specification for a detailed description of the process, but let me include below a summary of the activities involved:
Activity 1: Recording the Problem. Someone takes responsibility for making sure that no matter how the customer reports the problem (telephone, email, tin-can-and-string) the problem gets entered into the system.
Activity 2: Reproduce the Problem. A second person takes the description given and makes sure that the description is complete.
Activity 3: Correcting the Report. If the description was not complete, it goes back to the person who entered it to fill in the missing details. This is a sort of quality-loop on the report itself.
Activity 4: Identifying the Problem and Resolution. Development gets involved here to clarify what is happening, why it is happening, if it is a bug or not. If a fix is needed, then a new build may have to be produced.
Activity 5: Verifying the Resolution. QA gets involved again to second check that that the described problems was actually fixed.
Activity 6: Communicate Results. Regardless of how the issue was resolved, it needs to be communicated back to the customer in a way comfortable to them.
Activity 7: Audit and Record. This is a summary step in the process that allows the company to keep track of how things are going and possibly identify troublesome trends. (It is true that many good products today automatically capture this, but this process was created 10 years ago, and I prefer to keep to that documented process, than to deviate and have to document the process again.) Activity 6 and 7 are started in parallel because it does not matter which order they are performed in.
There are three main roles:
Customer Support: most likely a person who answers the phone when the customer calls, but they receive the communications by email or other means. In some cases there will be a specific support person assigned to each customer. Customer support performes activities 1, 3, and 6.
QA: The Quality Assurance team is providing two functions. Being relatively expert in the particular product, they are acting to resolve issues quickly without involving development when the problem is a known problem. If a fix is required, then the fixed version is tested to assure that it solves the exact problem that the customer reported. QA performs activities 2, 5 and 7.
Development: The people involved in the design and maintenance of the product, and the most expert on the product itself. While Customer Support and QA try to shield the developers from customer issues, ultimately the issues will come to development if not solved otherwise. Developers perform activity 4.
We can draw up the process and all the dependencies between activities in a BPM diagram using swimlanes to organize the activities for a particular role:
Click on the diagram to see a bigger version. The colors and shading is not strictly standard BPMN, so some of you may be interested in the BPMN classic view of the same process:
The first thing you might notice is that there are lots of branches, but very few branch gateway nodes. Instead, the activity is provided with multiple outbound arrows. Each arrow corresponds to a way that the activity can be concluded. This is, quite literally, the choice of the person performing the activity. Take a look at “Reproduce Problem”. You can see quite clearly that the performer of this activity must identify one of four significant conclusions: “Reproduced”, “Cannot Reproduce”, “Known Solution”, or “Duplicate”. It is very easy to see where the process goes depending upon which choice is made. The process designer can draw this directly on the process, without having to write scripts and conditional statements that test variables and branch depending upon values that have been stored in the variables. I have more on this in the “Multiple Conclusion Controversy” below.
Second, you might noice that there are a lot of implied loops. The “Reproduce Problem” step may determine that the problem is not reproducible, so the activity for “Correct Report” is activiated. The customer support person will add additional details and then send it back to QA to “Reproduce Problem” again. If QA still can not reproduce the problem they might again send it to the “Correct Report” problem. It could be passed back and forth between these people any number of times. In reality of course these are people performing the activities, so if it goes too many times they are likely to take steps to find out why it is taking so many step, or possibly to escalate to management. A similar loop exists between QA and Development when they don’t actually fix the right problem. Each of these loops represent a kind of “Quality Circle” where people are performing checks, and sending it back if not found acceptable. It is an easy way to model this fairly natural interaction between people.
Every activity is a facilitated human activity. This diagram is useful to explain to a customer support person, what other people will be doing in response to a customer issue. This diagram help people understand who else will be involved in response to particular decisions, such as whether the problem is reproducible or not. We can assume that there are also other automated computations, calculations, service requests, etc. involved in the process, but displaying them on this chart would make it more cluttered and harder to read, and therefor less useful for training people for how they are going to interact. Some people, though, will point out that this process is not “complete” because it does not include all the automated activities.
Multiple Conclusion Controversy
Let me address a comment that I often hear from people about BPMN processes who feel that “If a process has a branch, it should use an XOR gateway. It should not use two arrows coming out of an activity to branch.” This argument is based on the idea that activity nodes should be exclusively about performing actions, and gateways should be exclusively about the flow through a process.
The above Trouble Ticket process can be redrawn to use only XOR condition nodes to branch the process. It would look like this:
Compare this one (full size) with the original. There are three reasons why this is less satisfactory.
1. The diagram is more cluttered. Remember this is a simple process with only seven human activities. There are many business processes with many times this amount. The more nodes on the screen, the more visually cluttered it is, the harder to glance at and discern the meaning. The real question though is whether the addition of the XOR gateways actually makes the diagram more meaningful. Or the converse, if I remove the XOR gatways, how is the diagram less meaningful? The addition of the node (in my opinion) adds no extra value to the diagram
2. With the branch separated from the activity, it is far less clear why the process branches at this point. It could be because the human choice, or it could be anything else. You won’t know until you inspect the hidden metadata about the branch. Some branch nodes will the “data based” and some branch nodes will be “choice based” but that is not clear from the diagram. The “data based” branches must remain XOR gateways, but making the lines come straight from the activity make it entirely clear that the branch is because of the choice of the person performing the activity.
3. Part of the activity is to classify the result of the activity into a distinct number of “conclusions”. With the branch separated from the activity, it is less clear what choices the person has at that activity. You would be required to follow the lines out a ways. Consider the “Reproduce Problem” activity. If the lines instead come directly from the activity, it is clear that there that activity involves exactly four choices.
In conclusion, a simple rule that all process branching should occur at gateway nodes, causes diagrams that are lower quality and harder to read when it comes to human processes. When someone is trying to “automate” a process, the actions tend to be separate from the branches, but when someone is trying to “facilitate” a human process, it is more natural to remember that people often both do an activity and make a decision at the same time. For human processes, there is a huge advantage to incorporating the decision (choice) directly into the activity beacuse the process designer can simply draw the choice, and let the system deal with the details of capturing this choice from the user. This is again another difference between process automators and human process facilitators.
Conclusion
Find more on the trouble ticket process at:
http://www.kswenson.com/wiki/Wiki.jsp?page=TroubleTicketScenario
We need to start using a real human process fo revaluation of whether the existing BPM standards make sense. This standard process is documented and published. The diagram that I used in this article was created in TIBCO’s studio process designer, exported to XPDL, and then imported into Fujitsu’sInterstage BPM process designer, and an example of the kind of interoperability that you can expect today. The XPDL is linked to the page above, if you are interested.
|
