IT Operations Management

Video Activity

This lessons covers IT operations management. IT operations management consists of the following: - Management of the IT department - IT asset management - Systems lifestyle - IT policies This unit also covers IT Functional Objectives: - IT procedures - IT job descriptions and responsibilities - IT risk management process - IT service to the user T...

Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
13 hours 35 minutes
Difficulty
Intermediate
CEU/CPE
9
Video Description

This lessons covers IT operations management. IT operations management consists of the following: - Management of the IT department - IT asset management - Systems lifestyle - IT policies This unit also covers IT Functional Objectives: - IT procedures - IT job descriptions and responsibilities - IT risk management process - IT service to the user This unit also covers the IT Infrastructure library (ITIL). The core functions of the ITIL are: - Service support - Service delivery - Functional planning and management Participants in this lesson also learn about the IT department, specifically the roles of the: - IT director - IT Operations Managers - Systems architects - Information security manager - Information Systems Security analyst - Change control manager - Applications manager - Systems programmer - Software quality assurance tester - Systems analyst - Data entry staff - Media librarian - Help desk This lesson also covers using metrics to measure performance of an IT system, service level agreements (SLA) and outsourcing IT resources. [toggle_content title="Transcript"] So, thinking about the management of operations, we're trying to grow the organization in the direction which promotes the idea of effective and efficient management of the available resources. Those resources are not just systems. That includes people as well. So managing the IT department, we're trying to provide the basic security requirements of confidentiality, integrity and availability. When you get down to it, that is the foundation of any good operation. We need to also understand how to manage those assets that the IT department manages. That could be servers. It could be workstations, laptops, routers, switches, software licenses. This could be a significant percentage of the total gross sales of the organization. So that can potentially be a lot of money. So we want to be able to make sure that we're managing that expenditure and the effort properly. We need to pay respect to the systems development life-cycle, the SDLC. Also we talked in earlier sections about the capability maturity model, or the CMM. These are good frameworks to use and good measuring sticks to use to see that an organization is progressing along the desired path to maturity and to efficient operation. Lastly we're talking about our IT policies. Knowing that policies exist is one thing. Having them being available to everybody and enforcing them correctly is a more desirable goal. Our procedures need to be detailed enough in order for someone, as I was saying, that might be new to the position, to be able to pick up the documentation and do their job, without having to have their hand held the whole time. That's the mark of good documentation. Showing step-by-step what's required to get something done. We should be paying some attention to how we deal with our software licenses, how we deal with requests from users or trouble tickets that get opened by users. We also want to make sure that we have accurate and up-to-date descriptions of all of the roles and responsibilities. If those job descriptions are not accurate, then there could be a disconnect between what management expects and what the actual workers are doing. They need to understand what's required, what's expected and they should be able to refer to the documentation for their job description to double-check themselves. We need a mature risk management process. This means that risk is continually monitored, new risks are identified and studied and adaptations and all their modifications to the organization's way of doing things are then undertaken in order to address that risk. We have to remember that risk is never completely eliminated. There's always some level of risk in the various levels and operations of a given organization. Ultimately we have to support our users. This could be a generic end user but it could also be users that are running the business. They have similar requirements: the business user might have more authority to get things done quickly but the same requirements are in-place. We want our users to be happy and respected and we want to be able to make them feel like their voice is being heard when there's problems. One of the other areas where an organization can expand its maturity level is to implement programs like ITIL: the Information Technology Infrastructure Library. This means that you're trying to mature the organization's delivery of its services, trying to get those services to the highest level possible. So there's different audiences for ITIL. We have IT service providers, those directors which manage IT, our managers and other executives, like the CIO. They're interested in trying to get the most value for the budget that they expend on those IT services. Trying to get the most bang for the buck, if you will. We think about our core functions of IT. First on the list would be our service support. Whatever the services IT provides to the organization should be its highest priority, to keep those services running, especially since they may be critical to the overall mission, critical to the profit cycle. So we want to know that we can refer to different standards for doing this; perhaps the ISO 27000 series, our information security management system, ISMS. And then if we support those services, then the delivery becomes a natural flow for areas where we can look for room for improvement and think about how the delivery could be more effective, maybe from a time perspective. So capacity management is a factor here. Continuity of services. That sort of ties-in to the business continuity ideas or disaster recovery ideas. We also have to remember that there is a financial component to all of these things we're talking about. It's one thing to have really good ideas, but if the budget isn't there to implement them then we've got a gap. Then we consider our functional planning and management. This means that we're taking into account all of the resources; software, software licensing, our different hardware and facilities considerations, staffing, making sure that we've got some understanding of what's required for these different areas in the organization. Moving on to the personnel roles and responsibilities: we've got a lot of roles to discuss here and we'll just touch on each one of these a little bit to see what's involved. So, starting with our IT director, this person has the day-to-day responsibilities of managing IT. They are trying to exert their authority to make decisions for the group based on the requirements of the business and the available resources. Then we have operations managers. These are the people that are managing the help desk. Managing the network administration team, perhaps also managing the security team. So they've got their own day-to-day responsibilities, keeping everything running smoothly. Of course being overseen by the IT director. Then we have the systems architect. So systems architects work with the system analysts and they decide, at the big picture level, what needs to be done within the environment to deal with current challenges as well as planning for future capacity requirements. So they create the layout that best fits the goals of the business and also enhances the organization's ability to generate revenue. Moving on to our information security manager: the ISM. Typically this person has some professional credentials such as a CISSP, a CISM, and they try and apply the standards of management of information that they learned by gaining those credentials. Then we have a systems security analyst. This could be someone that's maybe a team lead or manager of your IT security team. Trying to make sure that they are expending their efforts and their budget appropriately to address the security goals of the organization. We can't forget about our change control manager. The change control manager has responsibility to make sure that the process of change control is managed effectively, that all of the appropriate people are present at change control meetings, and that there is a feedback loop to say that if a change is being rejected, "Here's why." And then there should be mechanisms in-place to resubmit a change and revise as needed in order to get things done. We have applications programmers. These are the people who developed the software that the organization may run on. Maybe they integrate that with commercial software. They're trying to work with systems analysts to understand what the requirements are for processing certain kinds of information. The information gets processed, it gets stored, it gets transmitted. This all comes together when the applications programmer and the systems programmer are working together, trying to get the best utilization of the available resources. So a systems programmer is more concerned with the foundation that the applications run on, but there's still some feedback between that group and the applications programming group. We have a software quality assurance tester, or testing group. Of course working with programmers and developers to make sure that the products they develop are actually working as expected, and providing some mechanism to address shortcomings or deficiencies or security risks. Then we have our network administrator; managing routers, switches, and so on, keeping the network running smoothly, dealing with the challenges of future capacity requirements. Server administrators or system administrators are dealing with server resources. You know, monitoring their performance knowing if they've got enough storage, enough processor and memory resources. Then we have database administrators that are obviously maintaining the databases. Typically, database administrators might have some experience as system administrators, or even systems programmers. So they build on that foundation to now manage all the data properly that the organization generates and uses to support its products and services. Then we have computer operators. These are more of junior positions. So they help systems administrators and database administrators by doing those lower-level tasks which they can then gain experience and knowledge to move up the ladder to a more advanced position. Systems analysts: this is a group that might work with the business side of the house. So they're trying to understand how to best utilize applications or how to best provide input to application design so that those tools and software packages can be used most effectively to generate revenue for the organization. Data entry staff play an important role. Sometimes this is done by the end user on a small scale, or you might have dedicated staff who are involved in data entry on a large scale. Media librarians: that's pretty self-explanatory. This is someone or a group who's taking care of all the back-up media or software media that are used, keeping track of where the information is stored, what it might contain and dealing with data retention policies. Then lastly we have our help desk. This is the first line of support when users or customers experience a problem. They call the help desk, get a trouble ticket opened and then the process begins to move towards resolution. Alright, so now let's think about how we use metrics. This is kind of a broad topic. There's lots of different considerations here. What we want to think about is what are the metrics that are most important to the organization? How do we generate them? How do we organize that information? How do we use it once it's been gathered? We have to think about ideally generating metrics automatically. The more automated metrics we can generate, the better. When we have to do this work manually, that means that we're going to be dealing with various human error problems. People get tired, they make mistakes, they're having a bad day, or they're not available, so reliance on a manual process is to be avoided. So what kind of metrics are we talking about? We have things like implementation metrics. Maybe you're rolling out some updates to a bunch of systems, or you're upgrading the operating system of a bunch of your servers. So you can say, 'Today we've got five out of 100 servers completed. Tomorrow it's seven. The day after it's twelve.' These are the kind of things that management's going to want to look at to make sure that you're making progress, you're reaching your milestones, and so on. There's also things like efficiency metrics. How long does it take to close the average trouble ticket? When someone calls the help desk, how long does it take before they get an email response saying that the ticket is being worked on? What kinds of ways can you measure the performance of your problem resolution? How many tickets are aged five days or more, ten days or more, 30 days or more? These are things you'd want to look at, as ways, of course, to look for room for improvement. We could then think about things like effectiveness, so how many tickets are open and closed in a given time period? That's a good example. Maybe users provide feedback to say that the ticket resolution was satisfactory or unsatisfactory. You might want to measure things like this. Then we have impact metrics. So having some way to deal with different types of incidents, maybe you decide to count them as an absolute number, or you say that there's a percentage, so 10% of our incidents deal with malware, 15% deal with unavailable access to resources, and so on. So coming up with reasonable categories here might be another way to look at your numbers and decide if the organization's doing a good job or not. Then we have purpose metrics. So what is the overall function of some process or procedure or service within your organization? We could have performance goals. These are, of course, generated by management or team leads, or possibly even as individuals. You might have your own personal goals. But performance goals at the higher level are going to be generated by management, since they are going to monitor all of these different factors and decide, 'This is a reasonable goal to go for,' and when it's reached, they can decide to possibly raise that goal, or keep it where it is and congratulate everyone on a job well done. We have performance objectives. This ties in with our performance goals to some extent. Maybe it says that if a ticket can't be closed within two hours, then we need to escalate. If it can't be closed within 12 hours, we need to escalate again, and so on. This ties the performance of the workers to some kind of a timeframe. Then we think about how the measurement units are actually derived. Do we use percentages? Do we use dollars? Do we use minutes and hours? days and weeks? These are all things that might be used interchangeably here and there, but picking the correct measurement type is important so that everyone knows what to expect. We have to consider our data sources. Where has this data come from? Can we rely on this source of data? Is it credible? Is it reliable? What about available evidence or the frequency of the collection of that data? Certain kinds of information might be collected much more frequently than others. So that needs to be understood and applied appropriately to the different requirements. An indicator is something that provides value to the reader of this data. So they can know that if this indicator is above a certain level, or below a certain level, this means it's good or this means it's bad. Maybe you even show some formulas involved in doing certain calculations. That helps the reader of the metrics to understand more fully what this metric really means. Then we can move on to our service level agreements. One of the first things you typically define with a service level agreement is what is acceptable in terms of downtime? If we remember we talked previously about the Six Sigma standard. 99.999% uptime. Or 99.999% defect-free. However you want to use that. That's an extremely tough standard to meet. For maintenance of a typical system, maybe you have a four-hour window once a week, or a four-hour window twice a week. That's pretty typical. We have to define our services. Users need to understand if they have a requirement to do their job or a requirement to get a problem fixed. What services are available from the available catalogue or menu of services that the organization provides? We have to think about the security requirements, as the organization is doing its job. How do we know if the processes that are being followed are secure? Are they promoting our goals of confidentiality, integrity and availability? Speaking of integrity, how do we ensure that the data that we store has integrity that we know that it's correct, that it hasn't been tampered with or corrupted? How often do back-ups get performed? That may vary depending on what the system does. Very high criticality systems might be backed-up continuously throughout the day. Other systems might be backed-up every evening, or maybe once a week. It just depends on what kind of data is there and who needs it and how available it needs to be. So a little bit more on SLAs: we have to think about the performance of the SLA. So when the SLA kicks in, meaning that there's some escalation required, or some activity that needs to happen, because some event has triggered it, how well does the SLA perform? How well does the staff perform in its duties? If the goal is to resolve all problems of a certain category within a short time-frame, like three hours, or two days, whatever it might be, that needs to be measured so that we can judge whether the SLA is effective. Another important thing, especially dealing with third parties or partners is trying to preserve a right to audit. This might be more difficult sometimes than others. It depends on what the service is that's being provided. But it's an important consideration because the primary organization wants to be able to audit the services it gets from other parties when it needs to verify that that party is doing their job correctly. What about if we want to change the SLA? How do we deal with that? Does it go through the normal change control process? Is there some kind of consensus reached with all the parties concerned? That's probably more practical. And then what does the service actually cost? Sometimes charges are direct from one organization to another. Other times you've got different departments within an organization cross-billing each other for different services like server hosting or application development, and so on. When we decide to outsource some IT functions, there are some important questions to ask. Why should we do this to begin with? It's possible that you don't have the expertise within the organization to address certain issues, so maybe bringing in an outside expert or a subject matter expert makes sense. It might be more expedient than bringing someone up to speed internally and it might be a more effective use of financial resources to do that. Maybe your current staff isn't getting the job done to the satisfaction of the managers rather. So they might decide that they're going to outsource certain things. We all know that help desk phone support is one of the more typical things that gets outsourced because it's possible that you can find competent people with the right kind of knowledge that will work for less because they're in another country where the standard of pay is lower. That may be a sad reality for some organizations. By moving jobs overseas, but ultimately if it supports the bottom line that may be a wise decision. Then we have to think about whether or not management has the proper procedures and processes in-place, but is just looking for a way to do things more cheaply. Again, moving some functions overseas, or to other workers that may not be as expensive is always an option. It may not be a popular option politically for instance, but the organization's goal is to generate revenue, so sometimes these types of decisions need to be made. Alright, so ISACA has some of their own recommendations for dealing with outsourcing contracts as far as what should be done and how that should be managed. First of all we think about what needs to be done before negotiations begin. Who are all the parties that are going to be part of this contract? How do we know what the legal jurisdiction will be? Especially when you're dealing with people in multiple countries, there could be issues with different types of laws and different regulations that the organization is now subject to because of where their workers are. As far as details go, we need to know what the services are that are being provided. The more detail the better in this case. How long does a contract actually last? What are the deliverables? What are the costs involved? Is it a fixed price contract? Is it time and materials? Are there provisions for dealing with unexpected expenses? Some more things to think about. Once the contract is underway, how do we measure the performance? Do we know that the invoicing and payment is going according to schedule? How do we deal with the right to audit requirement? Some organizations that are providing services may not have the resources to provide timely answers to the questions about audits. So that may be something that needs to be resolved during the contract phase to make sure that there's some compensation being considered there. How do we deal with non-performance? What kind of penalties might be involved? How do we deal with dissolving the contract if it's no longer needed, that service is no longer needed, or the organization decides they want to use a different vendor because the one they've chosen just isn't getting the job done to their satisfaction. We need to think about resolving problems. When we've got complaints from customers, complaints from users, how does that factor-in to what the organization does in relation to an outsourced service provider? What we don't want is too many layers of bureaucracy so that when a user complains, they've got to go through their own help desk and that gets transferred to another help desk and that gets moved to somebody else and finally they get to someone who can answer their question or solve their problem. That creates a lot of frustration and reflects poorly on the organization. [/toggle_content]

Video Transcription
00:03
>> So thinking about the management of operations,
00:03
we're trying to roll
00:03
the organization, and the direction which
00:03
promotes the idea of
00:03
effective, and efficient management
00:03
of the available resources.
00:03
Those resources are not just systems,
00:03
that includes people as well.
00:03
So managing the IT department,
00:03
we're trying to provide
00:03
the basic security requirements of
00:03
confidentiality, integrity, and availability.
00:03
When you get down to it, that is
00:03
the foundation of any good operation.
00:03
We need to also understand how to manage
00:03
those assets that the IT department manages.
00:03
That could be servers, it could be workstations,
00:03
laptops, routers, switches, software licenses.
00:03
This could be a significant percentage
00:03
of the total gross sales of the organization.
00:03
That could potentially be a lot of money.
00:03
We want to be able to make sure that we're
00:03
managing that expenditure, and the effort properly.
00:03
We need to pay respect to
00:03
the systems development life cycle, the SDLC.
00:03
Also, we talked in earlier sections
00:03
about the Capability Maturity Model, or the CMM.
00:03
These are good frameworks to use, and
00:03
good measuring sticks to use to see that
00:03
an organization is progressing along
00:03
>> the desired path to
00:03
>> maturity, and to efficient operation.
00:03
Lastly, we're talking about our IT policies.
00:03
Knowing that policies exist is one thing.
00:03
Having then being available to everybody, and enforcing
00:03
them correctly is a more a desirable goal.
00:03
Our procedures need to be detailed
00:03
enough in order for someone, as I was saying,
00:03
that might be new to the position to be able to pick up
00:03
the documentation, and do
00:03
their job without having
00:03
to have their handheld the whole time.
00:03
That's the mark of good documentation,
00:03
showing step-by-step what's required
00:03
to get something done.
00:03
They should be paying
00:03
some attention to how we deal
00:03
>> with our software licenses,
00:03
>> how we deal with requests from
00:03
users, or trouble tickets that get opened by users.
00:03
We also want to make sure that we have
00:03
accurate, and up-to-date descriptions
00:03
of all the roles, and responsibilities.
00:03
If those job descriptions are not accurate,
00:03
then there could be a disconnect
00:03
>> between what management
00:03
>> expects, and what the actual workers are doing.
00:03
They need to understand what's
00:03
required, what's expected,
00:03
and they should be able to refer
00:03
>> to the documentation for
00:03
>> their job description to double-check themselves.
00:03
We need a mature risk-management process.
00:03
This means that risk is continually monitored.
00:03
New risks are identified, and studied.
00:03
Adaptations, and where the modifications to
00:03
the organization's way of doing
00:03
things are then done undertaken,
00:03
in order to address that risk.
00:03
Because, we have to remember that risk
00:03
is never completely eliminated.
00:03
There's always some level of risk in
00:03
the various levels, and
00:03
operations of a given organization.
00:03
Ultimately, we have to support our users.
00:03
This could be a generic end-user,
00:03
but it could also be users that
00:03
>> are running the business.
00:03
>> They have similar requirements.
00:03
The business user might have
00:03
more authority to get things done quickly.
00:03
But the same requirements are in place.
00:03
We want our users to be happy, and respected,
00:03
and we want to be
00:03
able to make them feel like their voice
00:03
is being heard when there's problems.
00:03
One of the other areas where an organization can expand
00:03
its maturity level is to implement programs like ITIL,
00:03
the Information Technology Infrastructure Library.
00:03
This means that you're trying to
00:03
mature the organization's delivery of its services,
00:03
trying to get those services
00:03
to the highest level possible.
00:03
So there's different audiences for ITIL.
00:03
We have IT service providers,
00:03
those directors which manage IT, managers,
00:03
and other executives like the CIOs,
00:03
they're interested in trying to get the most value for
00:03
the budget that they expand on those IT services,
00:03
trying to get the most bang for the buck, if you will.
00:03
When we think about our core functions of IT.
00:03
First on the list would be our service support.
00:03
Whatever the services IT provides to the organization,
00:03
should be its highest priority
00:03
to keep those services running,
00:03
especially since they may be
00:03
critical to the overall mission,
00:03
critical to the prophet cycle.
00:03
We want to know that we can
00:03
refer to different standards for doing this,
00:03
perhaps the ISO 27002
00:03
series, or Information Security Management System,
00:03
ISMS, and then if we support those services correctly,
00:03
then the delivery becomes
00:03
a natural flow for areas where we can look for
00:03
a room for improvement, and think about
00:03
how the delivery could be more
00:03
effective maybe from a time perspective.
00:03
So capacity management is a factor here.
00:03
Continuity of services that ties into
00:03
the business continuity ideas,
00:03
>> or disaster recovery ideas.
00:03
>> We also have to remember that there is
00:03
a financial component to
00:03
all of these things we're talking about.
00:03
It's one thing to have really good ideas,
00:03
but if the budget isn't there to
00:03
implement them, then we've got a gap.
00:03
We consider our functional planning, and management.
00:03
This means that we're taking
00:03
into account all the resources,
00:03
software, software licensing,
00:03
or different hardware, and facilities
00:03
considerations, staffing,
00:03
making sure that we've got some understanding of what's
00:03
required for these different areas in the organization.
00:03
Moving on to the personnel roles, and responsibilities,
00:03
you've got a lot of roles to discuss here.
00:03
We'll just touch on each one of these a
00:03
little bit to see what's involved.
00:03
Starting with our IT director.
00:03
This person has
00:03
the day-to-day responsibilities of managing IT.
00:03
They're trying to exert
00:03
their authority to make decisions for
00:03
the group based on the requirements of
00:03
the business, and the available resources.
00:03
Then we have operations managers.
00:03
These are the people that are managing the help desk,
00:03
managing the network administration team,
00:03
perhaps also managing the security team.
00:03
So they've got their own day-to-day responsibilities,
00:03
keeping everything running smoothly.
00:03
Of course, being overseen by the IT director.
00:03
We have the systems architect.
00:03
So systems architects work with the system analysts,
00:03
and they decide at
00:03
the big picture level what needs to
00:03
be done within the environment
00:03
to deal with current challenges, and
00:03
as well as planning for future capacity requirements.
00:03
So, they create the layout that best fits the goals of
00:03
the business, and also enhances
00:03
the organization's ability to generate revenue.
00:03
Moving on to our Information Security Manager,
00:03
>> or the ISM.
00:03
>> Typically, this person has
00:03
some professional credentials,
00:03
such as CISSP, CISM.
00:03
>> They try to apply the standards of management
00:03
of information that they
00:03
learned by gaining those credentials.
00:03
We have a system security analyst,
00:03
this could be someone that's maybe a team leader,
00:03
or manager of your IT security team,
00:03
trying to make sure that they are
00:03
expanding their efforts, and
00:03
their budget appropriately to
00:03
address the security goals of the organization.
00:03
We can't forget about our change control manager.
00:03
Change control manager have
00:03
responsibility to make sure that
00:03
the process of change controls managed effectively,
00:03
that all the appropriate people are
00:03
present at change control meetings,
00:03
and that there is a feedback loop
00:03
to say that if a change is being rejected, here's why.
00:03
Then there should be mechanisms in place to resubmit
00:03
a change, and revise as
00:03
needed in order to get things done.
00:03
We have applications programmers,
00:03
these are the people who developed a software
00:03
that the organization may run on.
00:03
Maybe they integrate that with commercial software,
00:03
but they're trying to work with
00:03
systems analysts to understand what
00:03
the requirements are for processing
00:03
certain kinds of information.
00:03
The information gets processed,
00:03
it gets stored, it gets transmitted,
00:03
this all comes together
00:03
when the applications programmer, and
00:03
a systems programmer are working together trying
00:03
to get the best utilization of the available resources.
00:03
A systems programmer is more concerned
00:03
with the foundation that the applications run on,
00:03
but there's still some feedback between
00:03
that group and the applications programming group.
00:03
We have a software quality assurance tester,
00:03
or testing group, of course,
00:03
working with programmers, and developers to make sure
00:03
that the products they develop
00:03
are actually working as
00:03
expected and providing some mechanism
00:03
to address shortcomings, or
00:03
deficiencies, or security risks.
00:03
We have our network administrator managing routers,
00:03
switches, and so on,
00:03
keeping the network running smoothly,
00:03
dealing with the challenges
00:03
of future capacity requirements.
00:03
Server administrators, or system administrators
00:03
are dealing with server resources,
00:03
monitoring their performance,
00:03
knowing if they've got enough storage,
00:03
enough processor, and memory resources.
00:03
Then we have database administrators.
00:03
They're obviously maintaining the databases.
00:03
Typically database administrators might have
00:03
some experience as system administrators,
00:03
or even systems programmers.
00:03
They build on that foundation to now
00:03
manage all the data properly that
00:03
the organization generates, and
00:03
uses to support its products, and services.
00:03
Then we have computer operators,
00:03
these are more of a junior positions,
00:03
so they help systems administrators, and
00:03
database administrators by
00:03
>> doing those lower-level tasks,
00:03
>> which they can then gain experience, and knowledge to
00:03
move up the ladder to a more advanced position.
00:03
Systems analysts.
00:03
This is someone or a group rather
00:03
that might work with the business side of the house.
00:03
They're trying to understand how to best utilize
00:03
applications, or how to best
00:03
provide input to application design,
00:03
so that those tools, and
00:03
software packages can be used most
00:03
effectively to generate revenue for the organization.
00:03
Data entry staff play an important role.
00:03
Sometimes this is done by the end-user on small-scale,
00:03
or you might have dedicated staff who are
00:03
involved in data entry on a large-scale.
00:03
Media librarian.
00:03
That's pretty self-explanatory,
00:03
this is someone, or a group who's taking care of
00:03
all the backup media, or software media that are used,
00:03
keeping track of where the information is stored,
00:03
what it might contain,
00:03
and dealing with data retention policies.
00:03
Then lastly, we have our help desk.
00:03
This is the first line of support when
00:03
users, or customers experience a problem,
00:03
they call the help desk, get a trouble ticket opened,
00:03
and then the process begins to move towards resolution.
00:03
Now, let's think about how we use metrics.
00:03
It's a broad topic,
00:03
there's lots of different considerations here.
00:03
But what we want to think about is,
00:03
what are the metrics that are
00:03
most important to the organization?
00:03
How do we generate them?
00:03
How do we organize that information?
00:03
How do we use it once it's been gathered?
00:03
We have to think about ideally
00:03
generating metrics automatically.
00:03
The more automated metrics we can generate, the better.
00:03
When we have to do this work manually,
00:03
that means that we're going to
00:03
be dealing with various human error problems.
00:03
People will get tired, they make mistakes,
00:03
they're having a bad day,
00:03
or they're not available,
00:03
so reliance on a manual process is to be avoided.
00:03
What kind of metrics are we talking about?
00:03
We have things like implementation metrics,
00:03
maybe you're rolling out
00:03
some updates to a bunch of systems,
00:03
or you're upgrading the operating system
00:03
of a bunch of your servers.
00:03
You can say today we've got five
00:03
out of 100 servers completed tomorrow it's seven,
00:03
the day after it's 12,
00:03
these are the things that management is going
00:03
to want to look at to make
00:03
sure that you're making progress,
00:03
you're reaching your milestones, and so on.
00:03
There's also things like efficiency metrics.
00:03
How long does it take to close
00:03
the average trouble ticket?
00:03
When someone calls the helpdesk,
00:03
how long does it take before they
00:03
get an email response
00:03
saying that the ticket is being worked on?
00:03
What kinds of ways can you
00:03
measure the performance of your problem resolution?
00:03
How many tickets are aged five days or more,
00:03
10 days or more, 30 days or more?
00:03
These are things you'd want to look at as ways,
00:03
of course, to look for room for improvement.
00:03
We can then think about things like effectiveness,
00:03
so how many tickets are open, and closed in
00:03
a given time period, that's good example.
00:03
Maybe users provide feedback to say that
00:03
the ticket resolution was satisfactory,
00:03
>> or unsatisfactory.
00:03
>> You might want to measure things like this.
00:03
Then we have impact metrics.
00:03
Having some way to
00:03
deal with different types of incidents,
00:03
maybe you decide to count them as an absolute number,
00:03
or you say that there's a percentage,
00:03
so 10 percent of our incidence deal with malware,
00:03
15 percent deal with
00:03
unavailable access to resources, and so on.
00:03
Coming up with reasonable categories
00:03
here might be another way to look
00:03
at your numbers, and decide
00:03
if your organization is doing a good job or not.
00:03
Then we have purpose metrics.
00:03
What is the overall function of
00:03
some process, or procedure,
00:03
or service within your organization?
00:03
We can have performance goals, these are of course,
00:03
generated by management or team leads,
00:03
or possibly even as individuals.
00:03
You might have your own personal goals.
00:03
But, performance goals at
00:03
the higher level are going to be
00:03
generated by management since
00:03
they are going to monitor all of
00:03
these different factors, and decide this is
00:03
a reasonable goal to go for,
00:03
and when it's reached,
00:03
>> they can decide to possibly raise
00:03
>> that goal, or keep it where it
00:03
is and congratulate everyone on a job a well done.
00:03
We have performance objectives.
00:03
This ties in with their performance
00:03
>> goals to some extent.
00:03
>> Maybe, it says that if a ticket
00:03
can't be closed within two hours,
00:03
then we need to escalate.
00:03
If it can't be closed within 12 hours,
00:03
we need to escalate again, and so on.
00:03
This ties the performance of
00:03
the workers to some time frame.
00:03
Then we think about how
00:03
the measurement units are actually derived.
00:03
Do we use percentages,
00:03
do we use dollars,
00:03
do we use minutes and hours, days, and weeks?
00:03
These are all things that
00:03
might be used interchangeably here and there,
00:03
but picking the correct measurement type
00:03
is important, so that everyone knows what to expect.
00:03
We have to consider our data sources.
00:03
Where does this data come from?
00:03
Can we rely on the source of data?
00:03
Is it credible? Is it reliable?
00:03
What about available evidence,
00:03
or the frequency of the collection of that data?
00:03
Certain kinds of information might be
00:03
collected much more frequently than others,
00:03
so that needs to be understood, and applied
00:03
appropriately to the different requirements.
00:03
>> An indicator is something that provides
00:03
value to the reader of this data.
00:03
They can know that if there's
00:03
indicator is above
00:03
a certain level, or below a certain level,
00:03
this means it's good or this means it's bad.
00:03
Maybe you even show some formulas
00:03
involved in doing certain calculations.
00:03
That helps the reader of the metrics to
00:03
understand more fully what this metric really means.
00:03
We can move on to our Service Level Agreements.
00:03
One of the first things you typically defined with
00:03
a service level agreement is
00:03
what is acceptable in terms of downtime.
00:03
If we remember, we talked previously
00:03
about the Six Sigma standard,
00:03
99.999 percent up-time, or 99.999 percent defect-free.
00:03
However you want to use that,
00:03
that's our extremely tough standard to meet.
00:03
For maintenance of a typical system maybe you have
00:03
a four-hour window once a week, or
00:03
four-hour window twice a week that's pretty typical.
00:03
We have to define our services.
00:03
Users need to understand if they have a requirement
00:03
to do their job, or a requirement to
00:03
>> get a problem fixed.
00:03
>> What services are available from
00:03
the available catalog, or
00:03
menu of services that the organization provides.
00:03
You have to think about the security requirements.
00:03
As the organization is doing its job how do we
00:03
know if the processes that are
00:03
>> being followed our secure?
00:03
>> Are they promoting our goals of
00:03
confidentiality, integrity, and availability?
00:03
Speaking of integrity, how do we ensure that
00:03
the data that we store has integrity?
00:03
That we know that it's correct,
00:03
that it hasn't been tampered with, or corrupted?
00:03
How often do backups get performed?
00:03
That may vary depending on what the system does.
00:03
Very high criticality systems
00:03
might be backed up continuously throughout the day.
00:03
Other systems might be backed up every
00:03
evening, or maybe once a week.
00:03
It just depends on what data is
00:03
there, and who needs it,
00:03
>> and how available it needs to be.
00:03
>> A little bit more on SLAs.
00:03
We have to think about the performance of the SLA.
00:03
When the SLA kicks in,
00:03
meaning that there's some escalation requirement, or
00:03
some activity that needs to
00:03
happen because some event has triggered it.
00:03
How well does the SLA perform?
00:03
How well does the staff perform in its duties?
00:03
If the goal is to resolve
00:03
all problems of a certain category
00:03
within a short time-frame,
00:03
like three hours or two days, whatever it might be,
00:03
that needs to be measured, so that we can
00:03
judge whether the SLA is effective.
00:03
Another important thing about
00:03
especially with dealing with
00:03
third parties, or partners is
00:03
trying to preserve a right to audit.
00:03
This might be more difficult sometimes, and
00:03
others depends on what
00:03
the service is that's being provided.
00:03
But it's an important consideration,
00:03
because the primary organization wants to be able
00:03
to audit the services it
00:03
gets from other parties when it needs to verify that,
00:03
that party is doing their job correctly.
00:03
What about if we want to change the SLA?
00:03
How do we deal with that?
00:03
Does it go through the normal change control process?
00:03
Is there some consensus
00:03
reached with all the parties concerned?
00:03
That's probably more practical.
00:03
Then what does this service actually cost?
00:03
Sometimes charges are direct
00:03
from one organization to another.
00:03
Other times you've got different departments
00:03
within an organization cross-billing each other
00:03
for different services like server hosting,
00:03
or application development, and so on.
00:03
When we decide to outsource some IT functions,
00:03
there are some important questions to ask.
00:03
Why should we do this to begin with?
00:03
It's possible that you don't have
00:03
the expertise within the organization
00:03
to address certain issues.
00:03
Maybe bringing in an outside expert, or
00:03
subject matter expert makes sense.
00:03
It might be more expedient than
00:03
bringing someone up to speed internally.
00:03
It might be a more effective use
00:03
of financial resources to do that.
00:03
Maybe your current staff isn't getting the job done to
00:03
the satisfaction of the owners, or the managers rather.
00:03
They might decide that they're going
00:03
to outsource certain things.
00:03
We all know that help-desk phone support
00:03
is one of the more typical things that gets outsourced.
00:03
Because, it's possible that you can
00:03
find competent people with
00:03
the right knowledge that will work for
00:03
less, because there was another country
00:03
where the standard of pay is lower.
00:03
That may be a sad reality for
00:03
some organizations by moving jobs overseas.
00:03
But ultimately, if it supports the bottom line,
00:03
it may be a wise decision.
00:03
Then we have to think about whether,
00:03
>> or not management has
00:03
>> the proper procedures and processes in place.
00:03
But, as just looking for a way to do
00:03
>> things more cheaply.
00:03
>> Again, moving some functions overseas or to
00:03
other workers that may not
00:03
be as expensive is always an option.
00:03
It may not be a popular option politically,
00:03
for instance, but
00:03
the organization's goal is to generate revenue.
00:03
Sometimes, these types of decisions need to be made.
00:03
ISACA has some of
00:03
their own recommendations for dealing with
00:03
outsourcing contracts as far
00:03
as what should be done, and how that should be managed.
00:03
First of all, we think about what needs to be
00:03
done before negotiations begin.
00:03
Who are the parties that are going to be
00:03
part of this contract?
00:03
How do we know what the legal jurisdiction will be?
00:03
Especially when you're dealing with people in
00:03
multiple countries there could be issues
00:03
with different types of laws, and
00:03
different regulations that the organization
00:03
is now subject to, because of where their workers are.
00:03
As far as details go,
00:03
we need to know what the services
00:03
are that are being provided.
00:03
The more detailed, the better in this case.
00:03
How long does a contract actually last?
00:03
What are the deliverables?
00:03
What are the costs involved?
00:03
Is there a fixed price contract is at time,
00:03
>> and materials?
00:03
>> Are there provisions for
00:03
dealing with unexpected expenses?
00:03
Some more things to think about.
00:03
Once the contract is underway,
00:03
how do we measure the performance?
00:03
Do we know that the invoicing,
00:03
and payment is going according to schedule?
00:03
How do we deal with the right to audit requirement?
00:03
Some organizations that are providing
00:03
services may not have the resources to
00:03
provide timely answers to the questions about audits.
00:03
That may be something that needs to be resolved during
00:03
the contract phase to make sure that there's
00:03
some compensation being considered there.
00:03
How do we deal with non-performance?
00:03
What penalties might be involved?
00:03
How do we deal with dissolving
00:03
the contract if it's no longer needed,
00:03
that service is no longer needed?
00:03
Or your organization decides
00:03
that they want to use a different vendor,
00:03
because the one they've chosen just
00:03
isn't getting the job done to their satisfaction.
00:03
We need to think about resolving problems.
00:03
When we've got complaints
00:03
from customers, complaints from users.
00:03
How does that factor into what the organization does in
00:03
relation to an outsourced service provider?
00:03
What we don't want is too many layers of
00:03
bureaucracy, so that when a user complains,
00:03
they've got to go through their own help
00:03
desk, and that gets transferred to
00:03
another help to ask,
00:03
>> and that gets moved to somebody else.
00:03
>> Finally, they get to someone who could answer
00:03
their question, or solve their problem.
00:03
That creates a lot of frustration,
00:03
and reflects poorly on the organization.
Up Next