Wednesday, October 13, 2010
Call IT for Assistance
I shall explain an IT situation at work which will be amusing only to those who have experienced similar situations, or perphaps to anyone working in IT.
Every three months, my department runs a process which we have been running for years. However, there was a key component to that process which was provided by a specific member of IT. The process was automated, but this specific member - with a lot of seniority - adjusted the output of that process to fit our specific needs. When this process was created in 2007, IT asked our department to verify the output. Unfortunately, since verifying the output would require obtaining historical information that was just about impossible to obtain, everyone sort of looked the other way, IT kept complaining about our department not verifying the process, and we used whatever data the IT department supplied.
Then...that person quit. And the secrets of how that process was performed walked out the door with her. We have the query she ran, but we know nothing about what she did to the output to bring it to its final form.
Therefore, for almost six months now, we have not had this critical information. We have completed information up to March 2010. June 2010 came, and went. Still no IT support. We finally got some IT support last month, they managed to run the existing query for us - which provided incomplete information - and then...we fell off their radar. Now it's coming up past September 2010 and...still no data.
I have no authority to compel IT to give me what I want. Neither, I suspect, does my boss. So here is how it will go down.
1) My boss asks me to complain to IT. I complain to IT.
2) IT does nothing.
3) After 1) and 2) cycle for a while, and after we need to supply this information outside of the company, my boss kicks it upstairs to his boss - which is one of the four men in the company who are the bosses.
4) His boss assigns the IT shakedown to his partner in the Gang of Four, who I suspect is the designated nutcracker.
5) The nutcraker goes over and shakes down IT, the way the Mafia shakes down a storeowner.
6) IT devotes emergency resources to the problem. The result is a half-assed result that is very different from what we needed, but which we're forced to use in the end.
Currently, this is how our IT department works. "Busy" does not even remotely describe IT. IT's responsibility is not to information technology, it seems, but crisis management as IT is called upon to use its magic and put out a never-ending series of conflagrations as more and more of the company's business goes through IT.
The reason IT can't put out my small bonfire is because right now they are dealing with a massive ten-alarm bring-down-the-thunder conflagration which threatens to turn our business into ashes and will make weeping widows and distraught children. Yes, it is extremely hot where I'm sitting but trust me - the asbestos-clad forces of IT have seen much, much hotter things. "I can't deal with your piddly bonfire now - I'm up to my ass in fire hoses."
From my understanding of business - this will get much worse in the coming decades. With automation and artificial intelligence taking a greater and greater role, most functions of business will either be supplemented by computer technology...or replaced by it. (Read "Data Dump", on this website.) More and more jobs will become IT jobs. More and more of the business of a company will be influenced by something that happens in IT.
This will require an expansion of IT at some level. Maybe not at the data entry level or programming level - those levels are being outsourced - but at least an expansion at the watchful eyes level. At the "take the requests from the angry executives/workers/customers" level. At the input and output levels. Jobs might end up shrinking across the board, but IT's share of the remaining jobs that humans can still do will increase more and more over time.
I remember reading something said about computer programmers, namely that an good programmer is worth 10 average ones...and an excellent programmer is worth 10 good ones. My hope is that somewhere on site we have a good programmer who can solve our conundrum. Honestly, I'd be happy with an average programmer devoting his or her time to my bonfire, or even a poor one.
(* * *)
My mailing pledge to you:
a) If I ever send you an e-mail, the e-mail will have a subject header, one which is in some way relevant to the content of the body of the e-mail. It will not be "[No Subject]" but instead something like "Where's that library book you borrowed from me, you rat bastard?"
b) There will be more than a simple mysterious link as the body of the e-mail. The only exception to this rule will be in cases where I've actually exchanged e-mail with you and the body of the last e-mail message contains something like, "I'll send you a link in a follow-up e-mail, but I'm rushed for time so I might just send the link instead." Even then, it would be rare that I would send a link without any accompanying text.
c) If there is text in the mail, the text shall use proper grammar and capitalization, and it will eschew loose slang. You will not read anything like "hey guys :) check thizz out" but rather, "Here's an interesting link on the relationship between murder and bullying - I picked up this link at Fark.com and it's worth looking at." (This is merely a sample, as I would not repost any of fark.com's links.)
d) If the text uses proper grammar and capitalization, it will not read like a Markov Chain.
The above was inspired by three people I know whose e-mail accounts have been taken over by spammers. Cutting too close to home. I might end up dropping yahoo.com as a reachable e-mail address.
(* * *)
So I’m in the car and I’m in my new pants, getting ready to go to work, pulled up to the traffic light that’s just off the mall. And then I look down and notice….
…I can see my underwear. Not just the outline, but the white underneath. The pants are see-through. Ruth says that this is called the "pantyhose/slip moment." And even though I intend to wear these pants because they're so damned comfortable, work’s not the best place for that. So I turn around, go back, put on a pair of new jeans and I’m in the office at 9:15 am.
About 10:30 am, I feel something on the back of my leg. I forgot to take the sticky tag off. Good thing I was seated most of the day and no one noticed it.
Ate lunch. Some pizza sauce got on my white Land’s End shirt. Agh. Ever have that kind of day?
Subscribe to:
Post Comments (Atom)
3 comments:
What I've noticed regarding various IT departments' relation with the rest of their companies is that as more business processes are automated, real knowledge of the process—as in how you'd do the process with paper, pencil, and filing cabinets—migrates to the people in IT who have to implement the process. And who are the people who have to implement the process? Programmers, that's who. It's not the analysts whose job it is to document the process, because their work ends when they produce a document. It's not the non-tech project leads, because they need to present what's been coded as complying with the document. Aside: the disparity (why do businesses use the word "disconnect" when "disparity" is what they actually mean?) between these two representations and the actual manual process and its coded implementation is why so much business discourse is loaded with weasel and buzz words. The coders are left with a specification and the phone numbers (and email addresses) of the people who do the manual process, and as work progresses, the coders will call the line workers to make sense of the weasel/buzz word loaded spec, and it's during these phone calls (and emails) that the actual "knowledge transfer" takes place.
As you can imagine, such informal relationships also cause feature creep ("You know, while we're at it, we could also do this on that screen...") and changes to the substance of the process ("We always spit out a record of the transaction at this point, but those guys who get it just toss it out, 'cause they just want to know if the transaction succeeded or failed at the end of the day..." "So instead of individual statuses being sent out with each transaction, we could just issue a single report with every transaction at close of business?" "Oh God, yeah, that'd be so much better.") So now there's a new, undocumented process that only exists in the heads of the coders and the line workers who do the job (this may be a peculiarity of the places I've worked, but processes I've written applications to replace haven't been used to reduce headcount, but increase the productivity of the people doing the work manually; they have always been the first end users of the application. Some 19th century German said an increase in the "intensity and duration" of work would be the outcome of any introduction of automation in the workplace, rather than an increase in leisure time or intensity of work. Pretty smart for the 19th century, huh? Some writers on business and management still haven't gotten the memo on this, LOL) Eventually the original end users and/or coders leave, and the process becomes unintelligible to those left behind.
This is why there are so many legacy apps, and why the mainframe shall always be with us. The only way to really redo the application is scrap and redo the process from the ground up. This usually goes along with real seismic changes in the business: takeovers, layoffs, etc.
It's because of this dysfunctional reality that I know a coder who lives in a beach front property in Florida who works at home, supporting an application originally written by coders in New York and London for end users in NYC, Hong Kong, and London.
Some 19th century German said an increase in the "intensity and duration" of work would be the outcome of any introduction of automation in the workplace, rather than an increase in leisure time or intensity of work. Pretty smart for the 19th century, huh? Some writers on business and management still haven't gotten the memo on this, LOL.
Very interesting. So what is the difference between the "intensity and duration" of work vs. mere intensity of work?
This keys into something else I've learned - automation tends to slow processes down rather than speed them up. The primary example of this is the scan-and-sweep checkout counter, which believe it or not was slower than the "I'll-hit-three-keys-manually" old manual cash machines. I don't know why that is, but you might have some insight on that.
I went to look up "intensity and duration" and that 19th century writer and found http://www.korotonomedya.net/otonomi/caffentzis.html. All I can write is that it seems interesting, particularly in the difference between a "job" and "work".
Anyway, your comments on how processes end up implemented by the programmers - who then end up taking the knowledge out with them - is rather cogent. Whenever I create a dB from our UNIX tool, I find menu applications that I'll bet are never used again, but were created long ago by someone needing X, and the need for X left when the employee moved on.
I'd say intensity is output per unit time worked; duration is number of time units worked. So not only do you have to make more widgets in an hour, you have to do it for fourteen hours a day instead of just twelve.
Actually, bar code scanning always seemed faster to me. You just don't have to exert yourself as much for the same throughput. But that's just my impression. But it certainly requires less skill, so you can get just anyone to do it, whereas a good checkout person with the old-fashioned register was someone with training and experience.
Post a Comment