Don't Waste Your Time Chasing
Perfect
Your IT department is always
looking for the latest and greatest--while possibly leaving the back door open
to hackers. There are often easier, less complex safeguards available. And it's
not just in IT. Across your business, good enough is often good enough.
Not everything worth doing is worth doing to the nth degree.
Just like you can overthink and over-engineer your technology (See Can
You Have Too Much Technology?), you can foolishly try to achieve
levels of immediacy, proximity and precision that frankly no one really needs
or cares about--except maybe a few of your geeky engineers. Pursuing perfection
is a perfectly good way to burn through lots of cash, waste a lot of time and
energy, and frustrate your own people in the process.
In the real world, good enough is often good enough. (See Keep It Simple, Stupid.)
Trying to be better than that, or perfect, is more about your own neuroses or
bragging rights than an attempt to address the actual needs, requirements and
desires of your people, users or customers. The Six Sigma standard needs to
take a step or two back because; while it's a great goal and a significant
standard to shoot for in some businesses and contexts, it's a foolish fantasy
and a false formula in the majority of cases.
Constant observation
and measurement, ongoing review and iteration, and continuous improvement are
essential to your long-term success. But getting too far ahead of your skis,
spending more than you can afford shooting for levels of unnecessary precision,
setting standards that make no sense and add no value to your offerings, or
trying to address too broad a set of needs and customers are formulas for
expensive failures. Worse yet, these ever-elusive objectives distract you,
diverting attention and resources that need to be focused on far more critical
needs.
It's way too easy in our metric-driven digital world to fall in
love with stats and factoids and to pursue the numbers while losing sight of
the end game. (See The Curse of Microsoft Excel)
I remember long arguments with clients in one of my first businesses, where we
tracked customer satisfaction by making millions of phone calls each year to
consumers at home to determine how satisfied they had been with a recent
experience. It might have been a service visit, a sales encounter, a meal or a
hotel stay.
The clients (and their
internal bean counters) were always worried about the numbers - how many
interviews had we done, how many were fully completed, how many customers were
happy or unhappy. And, believe me, I know those were important considerations.
But what they never understood was that the most important measurement-- the
real goal of the effort--was to successfully connect with and, if necessary,
"fix" the customer. It was critical to show them that the reason for
the call was because we cared about them and their satisfaction-- not that we
needed to be sure that our CSI or NPS scores were up to snuff. And, even more
importantly, that we would try to resolve any problems or issues they had. If
we were interrupting something important, if they just didn't have time to
talk, if they didn't care to participate, the critical action was not to push
them or browbeat them into participating so we "completed" the
interview. The proper thing was to politely apologize for bothering them at a
bad time and hang up. Getting it right (not pissing the customers off) was more
important than getting one more incremental interview done.
We see similar
problems when IT departments exceed their brief and try to achieve levels of company-wide
information access without balancing the potential risks to the business
against the actual (not imagined or assumed) users' needs. Trying to create and
maintain ubiquitous data solutions can create unnecessary exposures from a
cyber security perspective without adding any incremental operational benefits.
The truth is that all of the people almost never need access to all of your
data, and especially not all of the time. This is the constant tension between
"real time" and "right time" access that too few companies
take the time to understand and manage.
One of my favorite
examples of how businesses are exposed to peril is the practice of giving
employees working remotely real-time access to inventory, shipping and billing
records on the company's main computer systems. Email and collaborative work
groups are obvious instances that demand real time access and therefore present
serious continuing risks--especially because overall employee compliance and
security diligence generally still sucks. Yet there are other important, but
less well-understood, areas where catastrophic business invasions, data and
financial manipulations, and ransom lockups and accompanying demands are just
as likely to arise.
The more frequent
exposures and most serious breaches in these areas come through the most
mundane of access points. Even worse, the entire business tends to assume that
there are no exposures of consequence inherent in the activities around such
basic processes. The facts are clearly otherwise and we hear every day about
outside penetrations in which company and customer data is stolen, company
funds and materials are misdirected and diverted, and millions of dollars of
false receipts and invoices are created and fraudulently paid. All right under
the noses of the company's financial and audit teams.
But there are some
fairly simple solutions and almost every business can figure out a method
within their SOPs to take a step or two back from the newest frontier and focus
on protecting their basic business instead. And here's a flash: you as the boss
need to worry about this because your IT guys are all about the latest and
greatest and fastest and they will quickly lead you off in the wrong direction
if you don't aggressively rein them in.
They know that it only
takes one security hiccup to bring the house down on their heads and they know
that such a breach is fairly inevitable and that, at best, they can only play
for a tie anyway against the bad guys. So, they spend their time focused on the
things they can control (and "improve") like access, speed and
response times even if the net effect is to increase the company's exposure to
external threats.
But you can do better
than that and greatly improve your company's odds of avoiding a data disaster.
And you can do it quickly and without spending a lot of time or money. There
are a bunch of approaches like air gaps and sneaker net systems, but I'm just
going to focus on the one I've used successfully in the past which I call the
DMZ approach.
To build your own DMZ,
you start by asking, who outside your four walls needs access to your internal
data and servers, why they need it, and how immediately they need it-- both in
terms of access and in terms of the timeliness of the data they are trying to
get. What you will find is that a lot of people need little or no immediate
access (if they ever need it at all) and that a lot more people can live very
happily with levels of access and immediacy that get the job done for them
without exposing or jeopardizing any of the company's critical servers and
systems. Once you scope and scale the problem, building a straightforward
solution is simple.
In our case(s), we
knew that we had hundreds of sales and support people in the field and they
needed to make regular inquiries. BUT they rarely needed the information they
were seeking to be real-time data. It was totally acceptable for more than 95%
of the inquiries for specified data to be delivered same day-- not last second.
And so, we built the DMZ, which was just a disconnected data repository into
which we dumped, and regularly refreshed, relatively current data up to 8 times
in a 24-hour business day. Everyone in the field could access that data any
time, but those inquiries were never connected or attached in any way to our
in-house servers. They had sufficient and timely information to respond to
their needs and their customers, and we had a one-way, bullet-proof system that
never let the outside world directly access our systems. Everyone in the place
slept better and no one was really any the wiser or missing anything they
really needed to do their jobs. You should ask the same questions of your own
systems before you have your own breach.
Bottom line: even if
we could give everyone on the team perfect information in real time and at all
times, we couldn't afford it and it wasn't worth the attendant risks. Good
enough to get the job done is good enough.