what the heck is that thingamy? #2

With our stuff getting into the last stretch towards being "finished" I'm now in the fortunate situation of discussing run-your-business stuff with real, live, actual end-users who have some experience using the large monolithic enterprise thingies.

What I hear a lot, followed by shaking of heads, are these three key terms:

Excel
Reconciliation
Reports, now please

Excel as in "I want my little special report so give me export of data into Excel". Producing "loose cannon balls" of manipulated, re-manipulated and time-sequestered data that leads to both humorous presentations (oops, same data, different assumptions... the graphs look a bit different don't they?) and the well known nightmare of:

Reconciliation. Take one spoon of data from accounting (gawd knows if all invoices have arrived), one dash ad-hoc report and four different spreadsheets that supposedly started with same set of data but which now are different. Result? Well, something iffy at best.

Reports. Well, if data sets are wandering, raw data dependent on snail-mail and multiple data sets each claiming to represent real life - what else than desperate calls at seven in the morning for reports by ten can be expected. Pestered from above, pester down, mess up your days.

On Red Team (changed colour this time) we have the well known monolithic enterprise software whose owners are big sponsors of the yachting industry (at least I can try earning some off them here).

And on the Blue Team we have as always the weed in the garden, thingamy.

Let's compare:

	Red Team	Blue Team
"My own special report" ability:	Export to Excel, apply logic at will, loose integrity and timeliness of data.	Create template easily once and for all, create your special report forever by push of button. Never loose integrity or value of raw data.
Reconciliation:	Required. Made difficult by said use of Excel, lateness of invoices etc. End result never exact.	Not required. One real world data is represented real-time by one data object in the system. Data captured by real world actions in real time. End of story.
Reports now! please:	Call, mail, request, cross fingers that nobody has to be dragged out of bed in California (heh, who cares, you're the boss)	Push button. Real time, now, any type, true now. Accessible by anybody, end of pestering, leave you to focus on task at hand.

I like learning about the "competition" :)

Comments

[john]

Elimination of reconciliation alone would be worth the price, but how can Thingamy eradicate the idiocy of humans? In student days I did a temp job involving reconciliation and saw how a single order got split over five separate deliveries due to packing issues and stock shortages. Only one of these contained the confirmation order - result chaos. Will Thingamy acknowledge that an order has been arbitarily split up like this? Never underestimate the human factor Sig!!!

[sig]

Ahh, good one John!

As the system works, "something real" has to "represent" the "delivery fact": You could set the system to accept a part as being delivered (as in invoice is now a "payable" and the part is actually stored in our warehouse as "inventory") when the chap in his system-delivered to-do task on the dock accepts the package, sets the "container" in his to-do interface to be Warehouse B, row 16 and presses complete. At that precise moment the parts are "inventory" and the pertinent invoice a "payable".

Now in your example you would have one single data item (confirmation) representing the delivery now as five different boxes coming at different times. If the system was expecting one package of 54 units the chap on the dock would have to "keep them in a corner" until he had them all - his to-do says "Expect 54 units" while he got 16, then 12, then 5... until he had what the to-do says, 54 units, at that point he chooses "container" hits "complete" and moves the stuff to the warehouse. Then and not before have the delivery been accepted and parts booked as inventory and invoice as payable.

In the system the "confirmation order" sheet following the packages would not have any practical meaning at all, if set up right the order was delivered by the system (thingamy) and the order/sending confirmation would be a fill-in in the system in effect creating the basis for the task for the chap on the dock, the invoice and the value of the parts as inventory.

Thus he would be less inclined to mess up as he would fill in while packing and sending, perhaps giving five different order/sending confirmation fill-ins and thus no mess up.

If the supplier has messed up anyway, the chap on the dock has very clear instructions - move-to-warehouse when you have received 54 units as per to-do.

If he on the other hand messes up it will be captured, every task is time-stamped and who-did-it stamped and what-did-he-do stamped :) And such transparency and accountability ususally leads to better practices over time...

That's how I would go about it, but you might choose a different way - as long as it represents real life in some form!

Was that too iffy? :)

[John]

Good try - but I would say that it may end up being a very big corner since there is no end to incompetence.

Indeed, in my real life example there was the added problem that the multiple deliveries were not due to lack of stock but to a computer system that measured the items in the original order and determined the most efficient way to pack them. I kid you not. This lead to multiple containers - one of which famously contained only one item (the rest of the items originally allocated to that container being out of stock). The multiple containers then got delivered by multiple deliverers. This was by the way a FTSE500 company.

Your guy would be waiting a very long time for all 54 items to arrive since some were out of stock and no this wasn't noted on the orioginal delivery invoice.

[sig]

Hehe... well, we do touch upon something interesting now:

A major part of the game is to "become better" is it not? Like sportsmen training every day if companies get better every day they might win!

That's an intrinsic part of thingamy - but what you paint here is the reality all too often, somebody outside the firm messing up everything! And that do happen :D

The question is - should that be allowed? I say no, you have a bad system unless you catch these useless ones, enables you to properly document (nothing beats bringing hard facts down to the minutes detail to a meeting!) and hit back asap.

A top athlete would do something about a bad performing racket or shoes - immediately, or non-performing support staff or whatever. Firms shall do the same.

So I think that my scenario above (BTW, you could design it differently though...) would catch, document and immediately tell you "those guys mess up my efficiency, they suck!"

A supplier is not only about right price and quality of product - here we see bad quality aspects that are important to the firm as well.

(A car manufacturer who relies on just-in-time supplies would not accept it for a second...)

In your real life example I would argue that it was not the supplier that failed, it was the receiver that did not catch it immediately, required better ways now and if not met, found another supplier!

That in a sense "good leadership" - measure performance real time and give specific feed-back and clear instructions of what you need. Think your real-life example showed bad leadership there ;)

[Luca]

Very good, Sig!

But let me point out a couple of importanti things...

I am involved with BIG ERP Systems and *big* customers since 10 years and since 10 years I am preaching the good news of using Excel (or equivalents) for your reporting needs.
In most of the cases this should involve "extracting" data into some kind of comma delimited text format.
But even better is to give them the ability through simple database external connections (ODBC or something similar) to access the data drirectly from Excel, using some kind of security / authorizations scheme.
You don't want everybody to see everything, do you?

This way your users not only have their formulas ready into their Excel spreadsheets, but also can refresh the data from inside Excel with just ONE click.
Without rebuilding the data, reading them into Excel, checking formulas, etc etc

And give the freedom to manipulate all data to whom is really responsible for reporting, instead of involving value-destroyers of any kind (always busy, understanding -nothing-of-business reports programmers, etc)

ROCK ON, Sig!

[john]

Yes improvement is the only feasible goal and I don't disagree with you about the leadership issue either, but I do think the distribution company in this case was astonishingly inept. I think also the problem may have been that a lot of the customers were relatively small enterprises who didn't think to complain as vehemently or as quickly as you rightly suggest they should have.

Maybe I'm revealing a need therapy to remove these repressed memories. I must let go. I must let go. Have a great weekend.

[Antoin O Lachtnain]

If you are talking about solving these three problems you are really talking about going in the direction of ERP, where you make the understanding of various business documents uniform across a company or even an industry. This is most effectively done by using a uniform business application across the industry.

As you wisely point out, the lack of uniformity across systems (manuf. systems, sales systems, bank systems, customer systems, paper systemts) is one of the main reasons reconciliation tends to be needed. In my view, that goes against the basic premise of thingamy, that businesses are non-uniform and require specialized systems especially developed. (In fact the truth lies somewhere in between.)

The problem with the split-delivery is a standard, adequately solved ERP problem. In general terms, the solution of not accepting partial deliveries into stock, not paying invoices for partial deliveries and (presumably) never making partial dispatches is simply a show-stopper for most manufacturing and distribution businesses.

When databases get fairly big, the reporting just doesn't run that smooth. You need to think about data warehouses and all the rest of it, basically because you need to layout the tables differently. It's not that data warehouses are a tremendously difficult concept, but building this sort of technology from scratch is heavy weather.

It's possible, but not easy to do that level of ad-hoc reporting in a user-friendly way. You have to differentiate between what your two teams are doing. If you want to do once-off reports, excel might be your best option. if you want to do regular reports, it probably isn't. But there are perfectly adequate packages you can buy off-the-shelf to do this stuff.

[sig]

Gentlemen, now we're touching some intereting points - and of course the call (curse?) of Excel is with us...

Now, two things:

1. Current systems are mostly "form based" as we still have the tendency to fall into the trap of thinking of a snippet of information as a "document".

Being object oriented you can cut those "forms" up into small pieces, no limits applies and "rebuild forms" as in reports using objects.

In fact I speak of objects representing real world objects - including the pertinent information as properties - and enabling objects to be built of other objects thus letting objects/information to be used anywhere.

As the sequence happens (workflow) properties are added or changed and metadata is captured - both equally important - now your report can display not only the properties but also who-did-what, what's the current value, where is it etc.

That leads to my main point about using Excel or not:

2. If you extract data outside the system you will not be able to register changes anymore - the report you see when you have manipulated a Excel sheet will be lost (and nobody, not even you will have a log of what logic you applied to the data).

Secondly, you will now have a "one man, one logic" manipulated data-set that presumably should represent some real-world object - thus you create the need for reconciliation.

So the question is "what for is the use of Excel good for?"

"To get my own kind of report" would be something of a generic one I suspect - so why not create that one using the "report" template builder - it should not be much more work than building a spreadsheet model.

And then you have the template forever, and for others, and all is captured and all are happy forever etc :)