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]

Getting more of what you want - Part 2

So, what is happening when successful entrepreneurial organizations find increasing challenges in what used to be intuitively easy for them -- namely, making more money tomorrow than they are making today?

Consider this: When the organization was purely entrepreneurial, likely it was small, had few employees, and operated in a relatively simple (unsophisticated) way. There were fewer things to touch and change -- fewer levers to push or pull -- to reach the desired result. Whatever management did produced nearly immediate reactions -- either good or bad. Feedback was frequently direct to the entrepreneurial leadership -- few or no layers of management or complexity, and fewer "dependencies" in the customer-to-cash stream.

In short, the entrepreneurial leadership was managing the organization as a single integrated "system" with a single goal -- to make more money tomorrow than it is making today!

However, with growth and (possibly) geographical expansion, the organization evolved from being integrated and homogeneous to being composed of departments -- the accounts payable department, the accounts receivable department, the production department, the shipping department, the receiving department, the sales department, ad infinitum. Of course, with departments came also department managers and maybe even layers of middle management.

More significantly, however, came a creeping mindset -- a mindset in executives and other managers that the sensible way to manage this growing organization is "by department." Instead of continuing to see the whole organization as one integrated "system" with a singular goal -- i.e., making more money tomorrow than it made today -- management began to set differing goals for different parts of the organization.

The production department's goals were all about quantities and quality; the sales department's goals were all about prospects, customers and orders; the accounting department's goals were tied to profits and cash flow; and so forth. Everyone was concentrating on managing their individual functions, but the "system" view that had brought early entrepreneurial success had almost entirely vanished from sight and memory.

Management had come to the (wrong) conclusion: That the way to optimize the "system" is to make sure the each individual part (department or function) is optimized. Unfortunately, without seeing this in the context of the "system" as a whole, this conclusion led to spending precious time, energy, and money on portions of the enterprise that did not add new profits and, in many cases, add operating expenses rather than decreasing them.

[To be continued...]

Contact me!