What can you do to recover after the hurricane,
tornado, cyclone, tsunami, fire, or other disaster has left your business
decimated. This Knowledge Briefing delivers strategies for preventing yet
another series of costly disasters—disasters of man-made origin!
Reduce Costs & Risks by Setting Effective Acquisition &
Utilization Criteria for Technology Assets
Starting
Over or Starting Out - When you begin
planning your new technology, or your post-disaster technology environment, take a very serious look at your genuine needs.
What level of hardware did you actually use prior to the disaster? What types
of software?
What were your problems, complaints, or cost concerns with previous products?
The answers to these questions should become the foundation for your purchasing
criteria—requirements & expectations applied to every prospective purchase.
Real World – Although
incredibly unfortunate, a disaster gives you a chance
very few businesses in the world will ever get—You get to correct previous
technology and operational mistakes and plan a substantially more
effective future infrastructure.
WIIFM – What's
in it (in this briefing) for me? There are two simple ideas in this Knowledge
Briefing that you can use to reduce technology costs and risks by as much as 30%.
These strategies are applicable to businesses recovering from a disaster as well as
new businesses building their first systems management (SAM or ITAM) infrastructure.
Take a look back. Prior to
the event, how did you actually use your technology? How did your
employees use it? Which of your tech products were genuinely doing the job? Which
weren't? What functionalities did you value the most? The least? How much were you
spending: On hardware, software, support, and services? How often did you
change over to new hardware or new software? Were those changes because you
needed the new products, or were they based on the vendor forcing you into the
evolution? Did you really need a “genuine Intel” processor computer, or would
an AMD or an Apple product be just as effective? Which of your prior software
products regularly exposed you as a hackers or piracy audit target? Are there
alternative products that you could use to reduce that exposure? Again, are
your requirements criteria well thought out and based upon measurable need?
Once you
have taken a serious look at the way your business technologies functioned before the
disaster, it is time to set the criteria that will guide the technologies you
will acquire
for the new systems environment.
Here is a big cost reduction. How difficult would it be to rebuild your technologies using open
source software? Many quality open source products are now available at no cost
or for drastically lower costs than the more popular comparable proprietary products.
The differences between open source and proprietary products in terms of functionality
and support for the average small business are not as significant as you would
expect.
For instance – Could your
company use a minimally priced open source product as its desktop
productivity suite—say for less than $100 per license? Or would you rather pay in excess
of $400+ per computer for a comparable proprietary product? Could you use locally
built computers, thus contributing to local growth, or would that
multi-national brand name
be more economical? Does your local tech community provide enough expertise to
support your tech products, or will you pay that multinational company for telephone
or email support?
Real World – Prior to
the disaster event, did you find yourself constantly patching
and fixing defective systems and software? How much would you save, in
labor alone, by moving to products that are not commonly targeted by
hackers, malicious code, and counterfeiters?
Unfortunately,
the vast majority of small- to medium-sized enterprises/businesses (SMEs/SMBs)
acquire and use technologies based upon reactive purchasing instead of the more
effective strategic purchase.
Do you want a guaranteed way to save money and
reduce risk? Try this easy and cost
effective process: Create a simple
acquisition criteria template for all future tech purchases. If your
personnel cannot clearly define and defend specific criteria for product
functionality, do not purchase the product. Acquisition criteria must be
directly tied to
the bottom line or to improved productivity; and don't forget to ensure that
those requirements
criteria have not been provided by the product vendor (as is very frequently
the case).
Real World: We used to
be able to acquire a perpetual license for most of our software-related
products. This license meant that we purchase the product one time and continue
to use it until we simply didn't need it any more—the one-time-fee license
continued onward at no additional cost. Such perpetual licenses are few and far
between in today's business technology environment. To increase their revenue
streams, many software publishers have switched to the subscription based licensing
scheme (SAAS) that requires you to pay an ongoing yearly fee to continue using
the product. Your previous “one-time” cost just became a significant, and
constantly escalating, repetitive expense. What's more, in many cases, if you
refuse to pay the yearly fee, the licensor can legally shut the product down
and deny use until you pay up or remove the product—very costly.
Setting
and following acquisition criteria need not be difficult. As you may have
gathered by the
previous content, there are certain immediate steps you can take to produce instant
savings. Remember the KISS principle? Consider the following...
Real World – Over 80%
of companies acquire technology assets (operating systems,
software, hardware, & etc) based on ad hoc criteria. Altogether too frequently,
ad hoc can be translated into pet product acquisitions. If you do nothing
more than take away the free money and establish credible control over the entire
acquisition process, you can reduce IT losses by as much as 30%.
Here's how you get caught...
Terrific Tales of Tremendous Terror – Over 60% of major businesses have refused to acquire
the latest operating system for their PCs. With their extensive buying power, these
large enterprises can afford to delay acquiring newly released products until
the software
publisher finishes their live beta testing (using customers to work the bugs
out of
products). Unfortunately, SMEs/SMBs do not have this leverage and must purchase whatever
operating system the hardware provider supplies. Result? The business technology
consumers least capable of absorbing financial losses due to technology
defects
are the very companies that must carry the load.
Fortunately,
and pretty much without precedent, an enormous number of PC systems builders
have finally made a stand and refused to load the “latest” operating system on customers'
PCs. Of course, the product was on the market for nearly six months before the
systems providers took action. Take a moment and estimate how much defective software products
cost you in down time, consulting fees for patch management, or simply inconvenience.
You may want to seriously consider using these losses to gain more mutual
benefit during your next hardware acquisition or software license negotiation.
Lots to consider. For now,
your assignment is to establish the purchase criteria that most
accurately fit your actual needs—measurable needs, not vendor hype. Work on criteria
for hardware, operating system, software, and support. Don't forget your
printers, copiers, fax systems, email, voice mail, even your cell phone needs.
Could you reduce ongoing costs by standardizing on a specific product or
service? Could the same standards
reduce your exposure to risk issues such as hacking, compliance audits, built in
obsolescence or constant unnecessary product feature bloat? I'll be back with
more.
Got questions? Comments?
Recommendations? Do you have horror stories of post-disaster experiences? Let
us know and we'll follow up. I'm Alan Plastow & I firmly
believe
that the more you know about managing technology assets, the less money you
will lose
to sharp technology industry practices. Or, on the down side, you could always become one of those asset managers who are not permitted to do anything more than count computers and software titles...
