I love enterprise software.
I've always loved it, and I love to see how end users use it.
A lot of the companies I advise,
people want to make the next tender or whatever,
but I'm always fascinated to walk into an office with a bunch of cubicles and
watch what those people do and the tools that
they have to do their job and how they like those things.
So here's the thing. A lot of them don't like the tools they have.
So, enterprise software can be really awesome and yet it's often not.
If you look at these stats here for CRM projects,
which are a reasonable proxy and a big part of enterprise software,
you see these kind of horrifying failure rates.
And that's sad because a lot of work goes
into these projects and a lot of people end up using
the software and not to attribute
the dynamics of the entire US economy to enterprise software,
but around 2007, you see a dip in labor productivity.
So, make better enterprise software and maybe you can
save the whole economy. How do we do that?
Well, I think there are four things that,
using Azure, we can readily improve on.
One is order taking versus consulting.
Because there's this idea that
enterprise software is this tool that automates what people do,
there is this idea that,
okay, well, we just need to go in,
and we'll talk to the sales department and the service department,
and they'll tell us what they want,
and we will put it up in the software and then we will give in what they want,
and if they don't like it, then we've done our job.
Well, that's part of what leads to these bad outcomes, I think.
Our job, and you'll be fully capable of
this by the end of the course in the specialization,
is to be consultants.
So, even if your job title isn't consultant,
you are learning the tools here to be able to help
others in a consultative way to drive to better outcomes.
And the tools you're going to learn here over the course of
this module are going to help you go into this enterprise software implementations,
engage within the parameters that you have available to you,
and drive to more valuable outcomes.
Here's an example of this,
a sort of simple dramatization.
Enterprise software person asks functional manager,
"What drop-down do you want to put here
because the enterprise software has a drop-down here?"
And they say, "Well, I'm really busy.
We did this in my last six jobs.
Why don't we just do the same thing?"
And we continue the cycle of way less than
optimal outcomes for enterprise software projects.
Building versus designing is a similar kind of symptom.
We're always on a schedule.
We're trying to roll this stuff out.
There's this idea that that software didn't work and nobody liked it.
So we'll get a different software,
and we'll put that in here now and now it'll fix everything.
And the reality is that doesn't work.
Enterprise software is this great products out there.
They're very fast sale.
Most of them, they're pretty easy to customize and tailor,
but you have to be thoughtful about that.
You have to iterate and think like
a designer using these tools that we have to get to a good outcome,
not just crank through it and just get it working.
And that's not always easy.
You have to develop a set of skills to basically sell your stakeholders on
why you need a little bit of time in
these other sort of non-obvious areas like learning about the users,
observing, working in short cycles that have
observation at the end to drive to these valuable outcomes.
And what you're learning through the course is specialization,
and you'll learn some IT specific tools here to do that,
totally related to this idea that we're
going to paper over the problems we have with software.
Well, anybody who's been doing
enterprise software for a while knows that that just doesn't work.
Software can do automation,
and it can standardize things,
and it can be beautifully built,
but ultimately, it's managers that run the business.
The software can help them.
But if you're not sure what your processes are,
if they're not well thought through with
people's roles in their inner change or handicapped,
software, by and large,
in this context can do very little to help that.
We need to think through what we want to have happen and
then allow software to automate and standardize it.
So, we often hear things like,
"We didn't work on order management process because
we figured we'd just get that from the software."
Well, that's a big mistake,
and we're going learn how to fix that here through process design as a prototyping tool.
Finally, big batches versus iteration.
We've talked a lot about this,
but it's just as common in enterprise software as it is everywhere else.
And it's important to work
through things in these small iterations that we have an Azure,
and it is massively helpful in enterprise software projects.
So, here's an example.
People want plans.
You're going to learn how to show them equally structured alternatives that do
a better job of iterating through
the ambiguity that's inherent in any big internal project.
Now, I don't have some magic silver bullet to fix
these things except for the fundamentals of Azure itself,
but we are going to go through a few practices that I think will really help you.
Here's how they tie in with the work we've been doing.
We're going to learn how to use the business model canvas to identify
key focal points in problem scenarios and
relate them back to the core of what's important to the business.
We're going to learn to use process design.
Now, I know you hear process design.
You probably have terrible associations with that.
But trust me, this process design technique, we're going to learn here,
is as facile and useful as the user stories and the prototypes that you've been seeing.
And then finally, we're going to learn how to organize and have
a regular cadence around iterative observation improvement with zero, 30,
and 90 day success criteria,
and that'll help us think about what's important here,
here and here as we progress through a piece of
functionality being implemented and handed over to users.
So, in the videos that follow,
we're going to move through these key points here,
and I think you'll find some really useful tools
to make your enterprise software and IT projects better.
Alex CowanFaculty & Batten Fellow
