Premier Issue of MC iSeries Technology Manager

[Guest.Visitor]

I have an interest in RFID. I noticed that you will be writing stories on the topic in the future. Here are a few more ideas. I have read a few books on the subject. It seems that RFID comes in three basic flavors: 1) Label oriented slap and ship, 2) Short and medium range active and semi active devices such as a tollway transponder or a Shell Speedpass, 3) long range tracking using GPS. None are cheap to implement and all seem to have a lot of gotchas along the way to final implementation. There are multitides of expensive consultants who will gladly take money to help you along. RFID is an annuity project. Feed the consultants once and they will not leave until you become assertive. Knowledge is power and the more an interested consumer of RFID services knows before the consultants arrive, the better for all. Thus, you can use this outlet as an informational and educational forum. Books cover the technical basics. They almost never cover the war story aspect. Nor do they cover the software side of the implementation. For example, now that you have this wonderful and functional RFID system, what do you do with it and how does the ERP interface work? Where are the real day to day problems? How can it be made cost effective in a situation where it is elective, as opposed to vendor required? How would a backup system be implemented in the case of primary system failure?

[MCWebsite.Staff]

Premier Issue of MC iSeries Technology Manager

This is a discussion about Premier Issue of MC iSeries Technology Manager.

Click here for the article.

[T.Stockwell]

Premier Issue of MC iSeries Technology Manager

Thanks for this feedback. The issue of "How can it be made cost effective in a situation where it is elective" is one of the most critical requirements facing IT. Too often management will not condone the implementation of a new technology unless it is required by a business partner in the supply chain. "Too expensive" or "We're not set up to do this kind of work" is often the excuse, even though the purpose of doing something elective with the technology may be the crucial difference that brings productivity and profitability to a process. In most cases, project engineering -- developing an engineering scheme for the use of a technology -- is not enough to convince management to invest in the technology. In many cases, even cost-justification skills are not enough to sway management's mistrust of IT. The only two scenarios that invariably bring about changes towards new technology are a) requirements that emanate from outside the organization (eg. the Wal-Mart scenario) or b) an existing process collapses because the technology is no longer supportable (eg. the Twin-ax terminal replacement scenario). Only in rare case (in my experience) is IT allowed to experiment with elective projects, and that is often permitted with the tacit understanding it's "cheap" and "won't hurt the status quo". (These "rules" sort of disappeared during the late 90s, when there was so much hype about technology. We may be coming back into an time when this kind of hype returns.) Global competition may, today, create new opportunities for IT to become creative again, but I believe the key will be how well IT managers are able to meld their skills with the current management psyche. IT has to "teach" technology to its management and gain its trust again. One of our goals is to create a journal for technology managers that is accessible to non-technical managers as well. Again, thanks for the input. ts