The New ERP - Part 6

Creating Your CRT (continued)

STEP 2:
Having collected some ten to 20 UDEs from your team, weed out any duplicates and make certain that the UDEs are clearly understood by everyone on the team, rewording them as necessary.

A well-written UDE will contain an "actor" as well as some description of the affects being experienced. For example, your team would need to clarify further a UDE that says only "poor quality." Is the poor quality coming from a vendor or is it your own organization that is producing poor quality? You will need to clarify such a UDE, after discussion, by rewriting it as, "We are getting up to 10% defect rates on widgets coming from ABC Company."

Another factor to consider: If you end up with UDEs that read something like "Because we get poor quality widgets from ABC Company, we end up with high scrap rates in Z-machine processing," then you will want to break that down into two UDEs that might read as:

1. "QC reports that we are getting up to 10% defect rates on widgets coming from ABC Company" and
   
2. "We have high scrap rates in our Z-machine process"

The reason for doing this is that the CRT construction itself will define the cause-and-effect logic, as we will see shortly.

Once everyone on the team is clear on the meanings of the UDEs you have collected, you and your team will be ready to move on to the next step in the construction of your CRT.

STEP 3:
In this step you and your team will begin linking the UDEs in cause-and-effect relationships. We usually do this on a whiteboard using the sticky-notes for the UDE entities and drawing in the connecting if-then arrows on the whiteboard.

Since one of the UDEs submitted had a "because" in it, and since we needed to break down that UDE into its components, we have a great place to start building our CRT, using logic already implied in our discussion.

Note that we assign numbers to the entities as we place them on the board. This is merely for the purpose of facilitating discussion and documentation. The numbers become shorthand for referring to an entity (rather than restating the entities whole contents).

One would read this beginning logic as: "IF [10] we get up to 10% defect rates on widgets from ABC Company, THEN [20] we have high scrap rates on our Z-machine processing."

There is additional logic implied in this statement, and everyone may be fully satisfied with the statement as it stands (understanding that the defective widgets consumed by the Z-machine process contribute to the defect coming out of that processing. However, if there are any questions, one might simply add a clarifying entity (as shown below).

Here you will note that we used a letter (rather than a number) to identify clarifying entities in the logic tree. We have also used an oval to encircle the two arrows leading from [A] and [10] to [20]. This oval constitutes an AND JOIN, so that the logic would be read as: "IF [10] we get up to 10% defect rates on widgets from ABC Company, AND [A] we use widgets from ABC Company in our Z-machine processing, THEN [20] we get high scrap rates on our Z-machine processing."

When building your CRT, you and your team may begin anywhere. Pick a couple of UDEs that appear to have some fairly obvious cause-and-effect relationship and place them on the whiteboard and join them with an arrow. Then seek the team's agreement with the logic before moving on to add another entity.

As I said, we typically do this on a whiteboard using sticky-notes. It can get a little messy. Don't let it get too out of hand, as you will need to be able to read your CRT and make sense of it when you're through building it.

However, once you're done with building it on the whiteboard, someone will have to undertake to document the CRT for review and final approval. We generally do this using Microsoft Visio, but any flow charting software (or even the drawing tools in Microsoft Word) could be used to create your final version. When creating a first draft, clean up the language in the entities to make the tree read relatively naturally from bottom to top. Also, rearrange the entities to reduce the number of arrows crossing one another just for general clarity.

[To be continued]