Welcome to the Idol framework. Updated course from Cyber Eri i G.
My name is Daniel Riley on your subject matter expert on the idol framework.
In this video, I'd like to talk to you about the service strategy section of the framework and specifically the goals and processes that formed up the service strategy.
When we're talking about goals, it's good to keep in mind what goal should be. And I like this acronym here. Goal should be specific, measurable, achievable, realistic and timely. That me, that should be smart.
So what we're going to do is we're gonna decide on a strategy to serve our customers and to to form that strategy, we're gonna use a market needs assessment and use case research These air a mix of qualitative and quantitative values that assess
where our market is and, uh,
where we can fit in and
serve the needs of clients.
part of our goals is to define what service is, and products will be offered to which markets
and also to define any capabilities that are missing from the organization that we need to fulfill these obligations, such as h r technical or material
eso these air a list of the mean processes that formed the service strategy.
Um, that strategy management service, portfolio management,
financial management, fry tea service is demand a management and business relationship management. We'll talk about all these in more detail in a moment,
the plan for the overall process here, Um,
each of our processes is going to follow this sort of pattern, starting with planning and decision making, which is where we're going to determine the course of ash actions for the process.
Then we're gonna organize through the process. Owners are and coordinate the activities of that they'll oversee.
Um, one of those people will, of course, be in charge of reading and managing the process on and finally, that will be involved without controlling, which is monitoring and reporting on the process, to make sure that it's still efficient and meets needs.
So talking about service strategy management, um, we're going to go through a process that's very much iterative, but
we like to lay it out on a line since there's a lot of information to take in here, Um, we're going to start with gathering facts, and this is internal and external information
about our company, how were structured as well as our competition and the market.
We're gonna use that to inform the next step, which is called a SWAT analysis. This stands for strengths, weaknesses, opportunities and threats. String some weaknesses form the internal part of the analysis.
Well, opportunities and threats form the outside the external.
we're going to review our inputs, which are the facts and the analysis that we've performed on. We're going to send this out to all the stakeholders, and we're going to find through three or four key ideas that
summarize our overall strategic plan for this market.
We're going to use that to create the next phase, which is a strategic matrix using the information we formed in the SWAT. The strengths and weaknesses,
Um, we'll get paired up strengths with opportunities and weaknesses with opportunities
and then strengths and threats and weaknesses and threats, and this just gives you a no overall idea
of where you need to work. Most effectively.
You'll do Wow, you'll take that and you'll define the strategies to fill these most important areas.
You'll create a list of objectives and then long and short term strategies
with mile markers to know how you're achieving them.
And then finally, once you come up with these plans, you'll send all of this out for reviewed all of the stakeholders who might come back with adjustments as necessary.
So to kind of just summarize this at a high level, What we're gonna do is assess the service providers offerings currently a CZ well, a czar, competitors and market needs.
We're gonna take a look at the current and potential market spaces that the company's heir operating in and identify possibly new verticals that the company could move to.
We're going to develop a strategy to serve our customers. And I think a key thing that hasn't been mentioned previously but is crucial to understand, is that the strategy to serve customers must focus on securely delivering service is to them by design,
Um, Maur and more regulations are requiring secure delivery by design. And it's
part of Idol should be
focusing on the security up by design.
Um, the service strategy management is not something that you do once at the beginning and then just leave in place. It's responsible for maintaining the strategy throughout this implementation or this it oration and all future generations as well.
So you should always start off
a cycle of your service management
by reviewing your current strategy and assessing if it's still applicability.
This is a graphic that I took off of the axle loose website, which describes the service portfolio on, and I think it's really good to use theirs as a reference,
so in the top portion, we have what is defined as the actual service portfolio that's broken into three trunks. In the beginning, you have an idea which gets fed into the service pipeline. The uppermost left portion.
Um, as that goes through your service pipeline, it gets form an idea to an operational service that operational service gets added into the service catalog.
Finally, as a service becomes outdated or superseded by other service is we may find the need to retire a service, and so that goes into the third right most section.
Now, all of these air tied together by a system called the Configure Mint Configuration Management system.
Um, the configuration management system is important for different reasons at different stages of the service portfolio. During the service pipeline, you need to be especially aware,
as you add service's or modify service, is how that has an effect on the overall configuration. You may need to plan to add new configuration fields or new entities. Altogether, for instance, is if it's service lives on its own server,
that server needs to be updated as part of the configuration management and therefore new entries have to be added. During the service catalogue, you're going to rely on the configuration management system to handle things like updating on dhe sensible settings.
the retired service's section is sort of the inverse of the service pipeline section. As you retire a service, you need to be aware of what configurations may no longer be necessary
or outdated, and make sure that you remove those according to change management process.
Finally, the lower section here, we won't dive into too much detail. It simply shows what sections make up the portfolio, and that is the customer portfolio of the list of people who are using particular service is an application portfolio,
which is service's, or applications that are in used to serve client means
Supplier and contract management Information system is often times used by resource planning, teams. These are more common
at higher levels in small businesses. This is more often than not, an ad hoc process.
Ah, customer agreement portfolio is a list of service level agreements and contracts with clients.
Um, the project portfolio is upcoming work that's going to come into or out of the service pipeline.
These are often times shared over long plan road maps and finally, the customer management databases, which hold all of the information for your relationship management, which we will talk about more.
So we're gonna create and manage this service portfolio, and I'll talk more about how we'll do that in a moment.
But once we're going to need to document, however we decide to create this
portfolio, we're going to need to document service, name
the life cycle state and don't get too caught up on the example. States that air here, um,
lifecycle states are oftentimes renamed to fit the organization that is using them.
We're going to list the service tight, which is Maur Generally applicability the three types that you can generally rely on seeing, or either client facing, which are what you are actually retailing as service's or products
ad. Then internal. Which air service is that our set up specifically to meet other internal business units and means
and finally external, which may be used to fulfill other business obligations, such as an information sharing service for 1/3 party platform.
Finally, we're gonna list customers using the service
and service sign up contacts. So these air the procedures and information that a client will need when they want to become a new user on the service or game or information. It's important to keep that documented somewhere.
All right, on the next section, we're going to document descriptions of the justification. This will most likely come in the form of the business analysis that we talked about in the strategy section. Previously. With the market analysis, we will find a justification for the service is
or the service modifications
we're gonna list are desired. Outcomes here are just in a couple of examples, but the idea of listing the desired outcomes is so that you have a record of intended consequences so that you can later analyze intended and unintended consequences.
On in the next section, I will talk to you about a principle
called the Good Heart Law which applies here, but we list are desired outcome so that we can monitor for this later.
We're also gonna want to keep track of package variations. This is different ways that we make. Sell the service for different client means. A good example here might be the way insurance is sold and bundle differently
based off of different levels of coverage.
And we're going to want to record our costs to serve in pricing, which will actually cover under the financial management for I t section. But we're gonna want to record it into our service portfolio so that, as we're analyzing our service is we can have a cost to serve and trending,
which will inform our pricing structure.
And then, of course, we're gonna wanna have any specific rules for the service and define any penalties or chargebacks for misuse.
We're gonna wanna have dependencies listed in these air service dependencies, which the current service must have to rely on in the example here, you might have an external dependency such as plastic molds from supplier X. If the service being documented cannot run
without molds from supplier eggs,
Uh, it needs to be documented here and it should be performed as a risk analysis
and the same thing with sight hosting from a vendor. There are lots of options for hosting, so perhaps you should also list backups.
Supported Service's are kind of the inverse of dependency service's, which are dependent upon this one. So when you write your service portfolio, if you're on a service and you've just written that it has a dependency on some other service internally,
you should also go to that service and update it supported service is as well
you're gonna want to include a link or an actual change road map in future generations. This simply is a list of decided changes that have been planned for some future release or update to the service.
And finally, on this you're gonna wanna glossary of the nomine clean shirt. Generally, when you create a service, you may have to invent or overload some words, which is the terminology that you used to describe the service.
And it's important to record these meanings and that the overloaded uses of words.
So that way, when we have discussions relating to this service, we can make sure that everybody has a same understanding as to what we're talking about
now, with software options for managing this
service, catalog management software is gonna help you improve the maintain ability of your service catalogue as going to do that by using the software to enforce things like the dependencies. Um,
if you go to retire a service that is dependent or supports another service,
then you don't want to do that without having an adequate plan to replace the service that you're retiring.
It's gonna make your catalog more portable because
this software is often times Web hosted these days, and therefore you can work on it across systems on dhe. Finally, you have error protection.
Now there are open source and paid options that already exist. I am a proponent of open source, and if it's in the option in your organization, I highly suggest checking into the open source options. If not, there are, of course, service is that will help you manage your catalog
and also from personal experience. It's not difficult to implement your own. I was asked to build a small application to manage the service catalog,
and I did so in Python in a matter of probably three months or less.
This is actually one of the models that I use from that to district to demonstrate the linking between two service is
you can see here that this is the information we've covered that you would want to.
I have documented, and in each side of the angle brackets would be a link to another section of the program which details the information. And the central arrows were what was maintained by the software. This is the software dependencies
So now, for the financial management for I t service is our main goals and process are gonna defying and manage the service budget, um,
and charging structure like we talked about, they're going to form a close to serve for each service and then for overall packaging.
They're gonna do this through a financial planning review, and then they're going to do an analysis and reporting on that review.
and these air generally going to inform the service guidelines and the invoice and structure for clients. This is the point at which we determine what
we're going to use per service if it's going to defer for each service.
So with the budget request allocation process. Um,
each service department
will have its own budget that it can spend either annually or every two years, depending on your organization. But the financial management processes will define, uh,
a specific way in which departments can request for new budgets, and they will define the guidelines for ways that the budget will be allocated fairly.
Now this is all part of the cost to serve analysis, and the budget request allocation process is informed by that in such a way
that previously I t had one budget and let's say the Human Resources Department had their budget.
Some of the I T budget was spent on
providing service is for the human resource is department. So we used business chargebacks as part of our cost to serve for Internal service is and for external service is we use the same idea to inform the overall pricing structure
and one thing that's worth mentioning is that direct costs to serve, such as money for packaging and materials are different than indirect costs to serve. For instance, if you have a lot of shipping
packages to a shipping warehouse might be an indirect cost that you would want toe work into your overall cost to serve if it makes sense for your application.
So this is kind of just a model of what we're talking about. You start with your planning, you go through your accounting processes, which is to record and, uh, analyze, and then you go into your reporting
and then you cycle back through your analysis of your changes.
It's moving on into demand management. This one is best viewed a CZ a two way
If you start with the patterns of your business activity, this is your client behavior. What of your service is air Most used versus which are not?
Um, this business process is a constant spinning wheel that feeds back to itself in the short run, whoever, it also creates a demand pattern, which can be seen as the belt feeding towards the right on the top.
This goes back to your service process. This is generally the backend processes which handle things like capacity planning. Now, these days, a lot of capacity planning has to do
with horizontal and vertical scalability, so horizontal scalability is the ability to bring up multiple instances
of your service next to each other. That way, no one particular part of the service,
uh, can become bogged down.
Vertical scaling is using one service, but throwing Maur resource is at that one service on, and this is not so popular anymore. With the the major use of cloud and virtual machines on Dr Containers, it's become
chic to use vertical scaling and form or predominant to use horizontal scaling.
So the Old World processes to estimate the service demand on playing for how the future will scale now with horizontal scaling. A lot of times this involves putting a kn elastic lewd balance or in front of your service to help distribute the traffic.
But there are other types of demand that are not for I T. And you're going to want to cover all of the demand on your customer service team. Your sales team demand levels change over time, so you're gonna wanna have a plan for measuring
and adjusting that as well.
Uh, as we talked about. Cloud service is often used auto scaling features which are horizontally scaling virtual machines which can be programmatically created and destroyed
on the reason that we do this is to balance between not enough service, and having idle resource is we don't ever want to have a client try to reach our service and have to turn them away because we are overloaded at the same time. We don't want to pay for computational Resource is
we're not going to be using.
So we're trying to optimize our cost efficiency there.
Now. The last section here is business relationship management. This is a key one because Idol is driven by market means and business relationship management is all about building the positive relationships with your clients. You're going to use those positive relationships with them
to gain insight from their use of your system,
a cz well as their views on their business. And that's gonna inform you as to what their upcoming needs might be and you can create service is that seem to appear just in time to meet new needs as they arise.
This also reduces risk of plant turnover,
because when you form a good relationship with your client, they're more likely to come to you with any concerns or problems. They're also more likely to give you information about upcoming needs they might see,
and this is all in support of the sustainability of the company. So when we were talking about business, modeling were mostly focused on the financial revenue aspect. But as we spread out, we also have to consider the other portions. And in this case
versus sport, we're supporting the sustainability. Like I mentioned,
here's kind of a model that I came up with of the business relationship. Flow starts with engaging your clients. That's the
and that goes into forming the relationship. And I went to former relationship. It's very important to understand the rules in that relationship. And it's
it's key to building trust with a client that they know and that you understand
what is OK in terms of their data or their information to be asking about what's appropriate and what is inappropriate.
you're gonna want to bring value to this relationship. It is not one sided. You're not only trying to get at their data or or their use of your service to better your business, but you do want to bring a value to them who want to service to truly meet a need for them.
And finally you're going to want to demonstrate that value to them so that you have that positive feedback. You can show them how you brought value to their relationship with you, and they will become more engaged and the relationship will become stronger and the whole cycle continues.
With that, we've come to the end of this video. I'd like to thank you for watching. And as always, if you have any questions, you can contact me on cyber harry dot i t my user name ist warder T w a r T E r.