So here's a quick checklist for the "not-very-shortcut" set of
practices that should set you ahead - if you can take the time
to follow them:
* Define your business requirements. Make sure that there are
not multiple views and goals (e.g., 25% cost reduction in WAN
bandwidth by Dec. 27) both within your organization, and between
you and the lines of business you're supporting. All too often
there are different versions of project objectives floating
around. At the same time, make sure you are clear on which
business services are affected by the change, and how.
* Clarify organizational and process needs. For instance, you
can't do data center consolidation right if you don't understand
the relationship between that project and your WAN performance.
Applications and services perform across an ocean of
interdependencies. That also means checking your organizational
processes and tuning them for superior collaboration - so that
in this case the NOC and the data center can work as a
collaborative team, not as finger-pointing adversaries.
* Audit. This is one of the scarier but more profound
requirements for "doing it right." You need to follow up the
implied "IT process audit" above and then document what the
infrastructure is, what your service-level agreements are with
external providers, what your SLAs are with internal and
external customers, and what management tools are in place to
support the project at hand. If you do this right, you'll
discover many surprises in all areas - unless of course you're
one of the very few organizations that took the time to get all
this right before. I'll also bet that you discover tool sets
with conflicting information used by different IT groups to
blame each other for problems.
* Baseline, analyze and plan. We're into more normal territory
here, and while there's a lot to say about this phase, I'll
focus on only two things. A real baseline means understanding
quality of experience, which is complex - including not only
availability and responsiveness, but also flexibility,
cost-effectiveness, appropriateness, and other metrics. Planning
also means understanding usage patterns and trying to get at the
hows and whys of service behavior before embarking on the
if-then tradeoffs for optimizing infrastructure.
* Establish and promote. Once your plan is solid, communicate it
- within your organization and externally to your customers.
Believe it or not, planned change is a good time to build
rapport with your customers and promote your value to the
business.
* Deploy and validate. The key thing here is to proceed in
stages and to validate as you go. It's also important to note
that before embarking on this stage, you should already have
worked out timing for any changes to SLAs and contracts with
external service providers.
* Reassess and begin again. Change is ongoing. If your WAN
rightsizing project has gone well, for instance, something new
is likely to be demanded. Rather than wait to be kicked from
behind, look proactively to, as the expression goes, "make
change your friend" in providing better services for your
clients.
Brak komentarzy:
Prześlij komentarz