Pacman chart

I'm going to join the anti pie chart crusade showing this cool chart from boing boing.



Sure pie charts are bad charts. If you like good data visualization, then see this presentation from gapminder. Highly recommended.

Teaching Backorder Processing with Cards

The backorder processing (BOP) is the process that takes into account the supply chain plan and updates the promised dates in the sales orders. Although BOP concepts are simple, the results are often hard for planners to understand. There are some BOP parameters that have a large influence in the results, and unless users really understand these parameters they will always feel uncomfortable when looking at the results.

Some of these BOP concepts are easier to explain by playing with some cards. Here is my proposal after having done some work with users to improve this process on SCM 4.1.

The types of cards include: "sales", "stock and "planned productions".

The sales have order entry date, order requested date, order confirmed date, material and quantity. The stock cards have material and quantity. The planned orders have material, quantity, completion date.

Some simple exercises:

1) Do a BOP with sort by confirmed date and check by confirmed date

2) Do a BOP with sort by requested date and check by requested date

The planners are expected to split the sales cards by materials, then for each material sort according to the sort date. Do the same sorting for the planned orders cards and put the stock cards in the top. Then they should match the requirements and receipts. As a final result they record in a piece a paper the order number and an up, horizontal or down arrow for improved, maintained and delayed dates.

Some other exercises:

3) A BOP with sort by save date and check by requested date (simulation of the ATP done when saving the orders).

4) A BOP with sort by confirmed date and check by requested date (planners are sometimes surprised how this can have results so different from the ones of exercise 2).

Then some more complex experiments can be done. For example, removing one planned order and doing the simulation exercise with the "new distribution" option set and unset.

These exercises there will probably trigger some discussion about the sort criteria, for example on using order priority or other new fields. It is also good to discuss the trade-offs of confirmation date stability and improvements on the first confirmed date.

And finally, but also very important, your users will thank you for some training time spent away from the computer screen.

The Lego Analogy

Very interesting this post about the use of the Lego analogy when presenting enterprise software. The Lego analogy is an old pal. I remember it in Visual Basic, then I remember seeing it in Zope talks. I never saw it in SOA, but then, I don't pay a lot of attention to the SOA thing.

I also think Lego is a bad analogy for enterprise software. From my experience with computers, the closest to the Lego would be a scripting language with a large object oriented library. One can just start assembling a bunch of pieces, no previous design needed, and in a reasonable amount of time get the wanted result.

When I think of SOA I usually think more of something in the line of the Garderna system. In most of these accessories water is meant to flow, so hoses of different dimensions are needed to connect the pieces. Since all pieces connect using the same standard, it becomes really easy to plug and unplug equipments to the hoses.






But people are not expected to build the equipments, each piece is already a fully working product. People just have to think what are the pieces they need for their garden (or they start by buying the basic and then add more when budget allows).






And of course, like models, all analogies are wrong, but some may be useful.