The Last Big Thing

Here’s an inspirational quote:

We always, it seems, are provided with a glut of material on the next big thing, and not enough on how to make the last big thing actually work. –Alec Sharp

It’s inspirational because it succinctly captures what’s wrong with this quote:

Accelerate the pace of change, and get employees conditioned to accept change. –Michael Dell

The problem is that change for its own sake is not good–it’s bad. Almost anything for its own sake is bad, especially if you have pretensions of customer service or a value stream. Change for its own sake is mere disruption, and without some demand up front and some payoff on the return, all change does is disorient people, and then turn them off. Nobody on either side of the counter wants to humor a manager’s substitution of “Change” for competence in delivering services.

I recall a passage which opened Betz’ first edition something along the lines of “Most corporate officers see IT as a bottomless money-pit which nobody who works there can explain because they themselves do not understand what they do.” That stings because it’s true. We in IT can complain all we want about how it’s a new discipline and uniquely vulnerable to the conceit of technical prowess masking a deep process incompetence, but at the end of the day, if we don’t bring in the big win, we are exactly those costly booger-eaters envisioned by the afore-mentioned corporate officers.

The IT staff struggles to work with whatever poorly-implemented cockamamie scheme was last year’s management fad. They rapidly discover that competence is for suckers, that hard work gets you burnt out, and that if they can just hunker down for long enough, the current disaster of broken agreements and death march projects will be replaced by the sunshine of the next unjustifiably optimistic phase of meetings, plans, and courses. Nobody has to learn their actual jobs if they can keep themselves busy attending Lean Six Sigma events, Seven Habits seminars, and conferences about trends in IT.

It’s not just dysfunctional–it’s downright pathological. And to what end? I’m not anti-Lean, but I am vehemently anti-moron, and Lean seems to be a refuge for morons from actual accountability into an imaginary realm where justifying a paycheck is as easy as falsifying data that somebody else is going to present. I was once in a Lean event where the lifecycle of a PC meant that the junkyard was formally my customer instead of the–well, customer. For three days the SIPOC up on the wall said that and we had to keep hammering away at the supposed experts to get them to accept our view that this was not a valid way to proceed.

Information work is fundamentally different from line work. When a person on a line is idled for a second per process, that second is lost. When an information workers is idled for an hour waiting on a call-back, that hour is not lost, because she will do something else productive. And if she issues a listing to ten co-workers to be verified and sent back on average one business day later, she first off does not lose a day of waiting, and she most certainly does not lose TEN DAYS of waiting. Perhaps I will be forgiven for pointing out that both of these have been relied upon in Lean events foisted onto my group. Counting parallel wastes in series is a useful trick when you wish to demonstrate that you have saved X man-hours equivalent of waste from some schlub department’s Lean event.

Thank Heaven that I objected loudly and clearly to these shenanigans, and refused to give this portion of the outbrief. Sure enough, a knowledgeable fellow asked just how it was that we claimed to have saved $70,000 per year on from a particular manpower type on one process, when that process only had a single man in that manpower type, and he made no more than $35,000 per year. I thanked the man for his question and deferred to the experts in these sorts of numbers, our Lean department: forty full-time employees with a set of outbriefs every two weeks which had better show at least enough man-hours saved every pay period to justify their own checks–or else why should they remain?

We have been doing Lean for perhaps five years now, and I have for about a week thought it would be a good opportunity to gather all of the claimed savings of man-hours in one pile, and see if that saving can be recognized either in man-hours not paid or in otherwise unexplained productivity boosts. Of course, we would have to apply the salaries of the Lean department against any gains as a cost, but if this stuff is worth doing, then it will show.

And if not then we should stop. The tools that are valuable within Lean were valuable before Toyota or Lean were even thought of, and will remain so outside of Lean. The tools will be even more valuable for being separated from a consulting priesthood based around “owning” the shifty definitions to some sophisticated-sounding foreign words for shockingly basic concepts. I don’t need a Japanese word like gemba to know that when the shit hits the fan, the fan room’s going to need a clean-up.

I live in Japan, and it is very trendy for Americans who have been here for an intermediate amount of time to prattle on about how great Japan is, and how bad Americans are. It was AWFUL, just AWFUL to have to be an American while Bush was President, and now we’re all so proud that we can hardly afford to keep the lights on with how the dollar is now toilet paper overseas. America-bashing has always had an appeal to a strain of Americans whom I do not care for, and the Toyota-worshipping Lean zealots are no different.

These are people who in their smug ignorance think that statistical methods were invented in the context of Lean, and that various tools and indices (such as sigma) are somehow copyrights, patents of the Lean Six Sigma set of very expensive courseware and resources, consultants and (God help us) “black belts”. The nice thing about Karate is that if a “black belt” is full of shit, he’ll be re-introduced to the mat until he leaves. In Lean, nobody ever gets fired because nobody dares speak up about the incompetence sitting next to them, for fear of being called out on their own complicity in making and bolstering extravagant claims.

I actually had a Lean person insist that I had not years ago used a fishbone chart to sort out timelines for shipboard evolutions. No, she said, that is a “cause and effect” chart, not for use in timelines. No, I said, you use it for cause and effect; I use it to coordinate ordered sequences of otherwise uncoordinated groups of activities. She kept arguing, and informed me that technically, it was an Ishikawa chart, and that I had been using it wrong. Gosh, with help like this, who needs the flu?

Meanwhile, we are struggling to implement portions of ITIL. THings were going well until (remarkably close the the end of the fiscal year) we abandoned the product we had heavily evaluated (BMC Remedy/Atrium, although my favorite was Oracle’s Siebel), and instead chose Tivoli on the basis of a powerpoint presentation and the words “Hurry up!” It is worth noting that at first we had not even considered IBM because the only experience any of us had with it was 100% bad.

Long story short, so here we are a hundred thousand or so dollars into this, and I say that we are just at the trailhead of IBM’s trail of tears. Now I’m not actually an expert, so I could be wrong, and that would not bother me so much. Ive admitted and apologized when I’m wrong, and I may need to do it after a while here. But until such time should come, here’s how I see it: We should run. IBM is working their vendor lock-in on us, and we have ZERO organizational expertise in SuSE Linux, DB2, CORBA, Tivoli, WebSphere, and guess what–those are the technology loadout for our Tivoli instance. I mention CORBA because we are now trying to hack and slash our way to making this damned thing work outside of IBM’s recommendations despite the cheapness of the VMDK-based setup we used, and our complete lack of familiarity with any of the tools or internals of the stuff we are using. Thank God we are our own and only customers in this. If anybody else saw this we would all be homeless.

We have actually moved backward from an ugly but more or less functional ticketing system based in Sharepoint to an ugly, slow and laborious, barely functional ticketing system in Tivoli. Not many people have any interest in setting up a CMDB, except as a big ol’ flat file that the Service Requests can peer into. Not that we have services defined–every ticket is a “Service Request”, but not against any particular service. Perhaps we should just call them Requests. Well, I just call them “tickets”, and I despair of convincing people that there’s more to this CMDB stuff than dumping a flat file once and saying “Well, Tivoli’s got it now”. You know, “How hard is it to store a username next a machine name?” That sort of thing. And without understanding the structure of what lies beneath the (fricking milions of) interfaces, that’s all it will ever be, is a flatfile that Tivoli applications can look into, but which none of the can update reliably (because of anomalies due to a lack of normaliz–oh, fuck it).

IBM offers tools to do this sort of stuff for us. Good-NESS, do they offer tools. They call them “accelerators”, which makes sense–they might as well call them transmissions, as without that stuff, you’re not going anywhere no matter what you burn up in the attempt. There is a module you can buy that will bring users in from (say) Active Directory. Naaaah, we’ll roll our own. There is a module to do some really whiz-bang discovery and classification; and it dumps this stuff in a sandbox for you to promote things from there into your actual realm of stuff that you want to bother with in the system. It’s really pretty amazing, but we’re a 2,500 user shop, tops, and that includes the PCs that run big screens and networked timeclock swipe stations.

A free component is the “Integration Composer” (ITIC) which actually manages a lot of that promotion and organization of stuff (this gets into CIs, which I get, and am not going to describe here) after that discovery piece finds it, but that’s just it–ITIC really wants to use output from the decidedly not-free discovery module. Oh, and we probably can’t set it up even if we *did* buy it, because of the afore-mentioned cheapness of the disk-image based setup we got shipped to us by a sales guy.

Meanwhile, I keep my precious asset data in a fairly-well normalized database (on MS SQL Server 2005, baby). The newest guy in my shop has proven adept at using the database and application I designed (and wrote) to go to town on the data found therein. He uses the interfaces I generated to do the daily work, and when there’s a bulk update or a peculiar data product needed, I go straight to the server. Data calls are no longer complex research projects, and our accuracy is now improving almost effortlessly–we are capturing updates. The rest of the crew keeps PCs moving to and fro to support the Operations team, disposes of things and documents the disposals, does receiving and for special evolutions (PC Refresh) even does the initial set-up.

We’re doing fair-to-middling on hardware asset management, and atrociously bad on software (it is tracked in several places, but not consolidated yet), and contracts are not even rolled into my arena yet. But we have a fair idea of where we stand in a maturity model sense, and am using Betz and Visible Ops to work my own mini-ITIL tucked over here into a corner in asset management. We have a refrigerator and some messy shelves we could clean up and call it a Lean event, and at any rate, maybe we can hold out long enough for the Tivoli bad trip to end, and either get better or go away; hopefully before the next wave of zombies from the Lean crypts.

Thank heavens I moved out to the warehouse over a year ago. If I were in that IT hallway, I would never get anything done. People think I’m wandering the desert. Wait until they see I’ve built a pyramid.