Here
to explore these and other enterprise IT performance issues, we're
joined by our co-host for this sponsored podcast, Georg Bock, Director of the Customer Success Group at HP Software, and he's based in Germany.
Gardner: Why is running IT
more like a business important? Why does this make sense now?
Aarnink:
Over the last year, whenever a customer asked us questions, we
delivered what he asked. We came to the conclusion that delivery of
every request that we got was an intensive process for which we created
projects.
It was very difficult to make sure that it
was not a one-time hero effect, but that we could deliver to the
customer what he asked every time, on scope, on specs, on budget, and on
time. We looked at it and said, "Well, it is actually like running a
normal business, and therefore why should we be different? We should be
predictive as well."
Gardner: Georg Bock, is this something you are seeing
more and more of in the field?
Trend in the market
Bock:
Yes, we definitely see this as a trend in the market, specifically with
the customers that are a little more mature in their top-down strategic
thinking. Let’s face it, running IT like a business is an end-to-end
process that requires quite a bit of change across the organization -- not
only technology, but also process and organization. Everyone has to
work hand in hand to be, at the end of the day, predictable and
repeatable in what they're doing, as Richard just explained.
That’s
a huge change for most organizations. However, when it’s being done and
when it has lived in the organization, there's a huge payback. It is
not an easy thing to undertake but it’s inevitable, specifically when we
look at the new trends around cloud multi-sourcing, mobility, etc.,
which brings new complexity to IT.
You'd better have
your bread and butter business under control before moving into those
areas. That’s why also the timing right now is very important and top of
people’s minds.
Gardner: Tell us a bit
about Achmea, the size of your organization, and why IT is
so fundamentally important to you.
Aarnink: Achmea is a large insurance provider in the
Netherlands. We have around eight million customers in the Netherlands
with 17,000 employees. We're a very old and cooperative organization,
and we have had lots and lots of mergers and acquisitions in the last 20
years. So we had various sets of IT departments from all the other
companies that we centralized over the past years.
If you look at insurance, it's actually having the
trust that whenever something happens to a customer, he can rely on the
insurer to help him out, and usually this means providing money. IT is
necessary to ensure that we can deliver on those promises that we made
to our customers. So it’s a tangible service that we deliver, it’s more
like money, and it’s all about IT.
Of the 17,000
employees that we have in the Netherlands, about 1,800-2,000 employees
work in the centralized IT department. Over the last year, we changed
our target operating model to centralize the technologies in competence
centers, as we call them, in the department that we call Solution Development.
We created a new department, IT
Operations, and we created business-relationship departments that were
merged with the business units that were asking or demanding
functionality from our IT department. We changed our entire operating
model to cope with that, but we still have a lot of homegrown
applications that we have to deliver on a daily basis.
Changing
the department and the organizational structure is one thing, and now
we need to change the content and the applications we deliver.
Gardner: How
has all this allowed you to better manage all the aspects of IT,
and make it align with the business?
Strategy and governance
Aarnink: To answer that question I need to elaborate a little bit on the strategy and governance department, which is actually within the IT department. What we centralized there were project portfolio and project steering, and also the architectural capabilities.
We
make sure that whatever solution we deliver is architectured from a
single model that we manage centrally. That's a real benefit that we
gained in centralizing this and making sure that we can -- from both the
architecture and project perspectives -- govern the projects that we're
going to deliver to our business units.
Bock: Achmea is a
leader in that, and the structure that Richard described is inevitable
to be successful. ERP for IT, or running IT as a business, the
fundamental IT processes, is all about standardization, repeatability,
and predictability, especially in situations where you have mergers and
acquisitions. It’s always a disruption if you have to bring different IT
departments together. If you have a standard that’s easy to replicate,
that’s a no-brainer and winner from a business bottom-line perspective.
In
order to achieve that, you have to have a team that has a horizontal
unit and that can drive the standardization of the company. Richard and
Achmea are not alone in that. Richard and I have quite a number of
discussions with other companies from other industries, and we very much
see that everyone has the same problem, and given those horizontal
teams, primary enterprise architecture, chief technology officer (CTO)
office, or whatever you like to call those departments, is definitely a
trend in the industry and for those mature customers that want to take
that perspective and drive it forward that way.
It’s not rocket science from an intellectual perspective, but we have to cut through the political difficulties.
But
as I said, it’s all about standardization. It’s not rocket science from
an intellectual perspective, but we have to cut through the political
difficulties of driving the adoptions across the different organizations
in the company.
Gardner: What sort of problems or issues did you need to resolve as you worked to change
things for the better?
Aarnink: We looked at the
entire scope of implementing ERP for IT and first we looked at the IT
projects and the portfolio. We looked at that and found out that we
still had several departments running their own solutions in managing IT projects and also budgets. In the past, we had a mechanism of only
controlling the budget for the different business units, but no
centralized view on the IT portfolio, as a whole, for Achmea.
We
started in that area, looking at one system of record for IT projects
and portfolio management, so we could steer what we wanted to develop
and what we wanted to sunset.
Next, we looked at
application portfolio management and tried to look at the set of
applications that we want to currently use and want to use in the future
and the set of applications that we want to sunset in the next year and
how that related to the IT project. So that was one big step that we
made in the last two years. There's still a lot of work to be done in
that area, but it was a big topic.
Service management
The second big topic was looking at service management. Due to all the mergers, we still had lots of variations on IT process. Incident management was covered in a whole different way, when you looked at several departments from the past.
We adopted service desks to cater to all those kind of deviations from the standard ITIL
process. We looked at that and said that we had to centralize again and
we had to make sure that we become more prescriptive in how these
process will look and how we make sure that it's standardized.
That
was the second area that we looked at. The third area was more on the
application quality. How could we make sure that we got a better
first-time-right score in delivering IT projects? How could we make sure
that there is one system of record for requirements and one system of
record for test results and defects. That’s three areas that we invested
in in the first phase.
Lots of change going on
Gardner: What have you have seen in the market that leads you to believe that
ERP for IT is not a vision, but is, in fact, happening, and that we're
starting to see tangible benefits?
Bock: Richard very much nicely described real,
practical results, rather than coming up with a dogmatic, philosophical
process in the first place. I think it’s all about practical results and
practical results need to be predictable and repeatable, otherwise it’s
always the one-time hero effort that Richard brought up in the
beginning, and that’s not scalable at all.
At some point you need process, but you shouldn’t try that dogmatically. I also hear about the Agile versus the waterfall,
whatever is applicable to the problem is the right thing to do. Does
that rule out process? No, not at all. You have to live the process in a
little different way.
Technology always came first and now we look for the nail that you can use that hammer for. That’s not the right thing to do.
Everyone
has to get-away from their dogmatic position and look at it in a little
more relaxed way. We shouldn’t take our thoughts too seriously, but
when we drive ERP for IT to apply some standard ways of doing things, we
just make our life easier. It has nothing to do with esoteric vision,
but it's something that is very achievable. It’s about getting a couple
of people to agree on practical ways of getting it done.
Then,
we can draw the technological consequences from it, rather than the
other way around. That's been the problem in IT from my perspective for
years. Technology always came first and now we look for the nail that
you can use that hammer for. That’s not the right thing to do.
From my perspective,
standardization is simply a necessary conclusion from some of the
trial-and-error mistakes that have been made over the last 10-15 years,
where people tried to customize the hell out of everything just to be in
line with the specificity of how things are being done in their
particular company. But nobody asked why it was that way.
Aarnink: I completely
agree. We had several discussions about how the incident process is
being carried out, and it’s the same in every other company as well. Of
course there are slight differences, but the fact is that an incident
needs to be so resolved, and that’s the same within every company.
Best practice
You
can easily create a best practice for that, adopt it within your own
company, and unburden yourself from thinking about how you should go for
this process, reinvent it, creating your own tool sets, interfaces with
external companies. That can all be centralized, it can all be
standardized.
It’s not our business to create our own
IT tools. It’s the business of delivering policy management systems for
our core industry, which is insurance. We don’t want all the IT that we
need in order to just to keep the IT running. We want that standardized,
so we can concentrate on delivering business value.
Gardner:
Now that we've been calling this ERP for IT, I think it’s important to
look back on where ERP as a concept came from and the fact that getting
more data, more insight, repeatability, analyzing processes, determining
best processes and methods and then instantiating them, is at the core
of ERP. But when we try to do that with IT, how do we measure, what is
the data, and what do we analyze?
Richard, at Achmea, are you looking at key performance indicators (KPIs)
and are using project portfolio management maturity models? How is it
that you're measuring this so that you can, in fact, do what ERP does
best, make it repeatable, make it standardized?
The IT project is a vehicle helping you deliver the value that you need,
and the processes underneath that actually do the work for you.
Aarnink:
If you look from the budget perspective, we look at the budgets, the
timeframes, and the scope of what we need to deliver and whether we
deliver on time, on budget, and on specs, as I already said. So those
are basically the KPIs that we're looking for when we deliver projects.
But
also, if you look at the processes involved when you deliver a project,
then you talk about requirements management. How quickly can you create
a set of requirements and what is the reuse of requirements from the
past. Those are the KPIs we're looking for in the specific processes
when you deliver an IT project.
So the IT project is a
vehicle helping you deliver the value that you need, and the processes
underneath that actually do the work for you. At that level we try to
standardize and we try to make KPIs in order to make sure that we use as
much as possible, that we deliver quality, and we have the resources in
place that we actually need to deliver those functionalities.
You need to look at small steps that can be
taken in a couple of months’ time. So draw up a roadmap and enable
yourself to deliver value every, let’s say 100 days. Make sure that
every time you deliver functionality that’s actually used, and you can
look at your roadmap and adjust it, so you enable yourself to be agile
in that way as well.
Print to Page
Blog Home
All Blogs
RSS
