Subscribe
Share
Share
Embed
Authentic, Authoritative, Unapologetic ServiceNow commentary by Cory "CJ" Wesley and Robert "The Duke" Fedoruk
. Duke: All right, folks.
Today we have a very, very
special treat for you.
We are joined by our guest of honor, Mr.
Paul, Charlie from Automate Pro.
Paul, why don't you give a quick intro
and tell us exactly what Automate Pro is.
Paul: Good morning, Rob.
Uh, delighted to be here.
Thanks for having me on.
Uh, super excited about this.
so Automate Pro fundamentally, it's a
test automation and DevOps solution.
Solution targeted specifically at
ServiceNow, and our vision of what
Automate Pro was all about was to create
the world's leading platform to enable
customers of ServiceNow to release and
upgrade as quickly and easily as cost
free and as risk free as possible.
Duke: that sounds like something I want.
Um, and I, I'm excited about this
because Paul and I have, done a
showcase on Automate Pro before if
you wanna actually see it happen.
We'll have a link in the
description below, to the video.
Paul and I did a while back.
It should be still a
good video, right Paul?
I mean, it's a couple years back now.
Paul: It was a few years ago.
Enjoyed doing that.
, it was a great video things have moved
on obviously since then, but a lot of the
while all of that content's still valid.
We just do it even better
and even faster now.
Duke: Yeah, I can't, like, this is why,
another reason why I was dying to get you
on the podcast because the whole concept
of testing is evergreen because basically
nothing out there is making it easy.
I'll just go ahead and say
it, like is a really scaled,
like, has everybody really got.
The, the sum of their platform
in a f ready, and they're pushing
that button every release just to
make sure, or is that an illusion
that we've built for ourselves?
Paul: I think the, the reality is that
people are, are struggling to make it do
exactly what they want it to do and give,
give them the coverage that they need.
I think there is, there is a place
for a tf I think certain, uh,
smaller ServiceNow customers may
find that, gives them what they need.
Where we really find the white space, for
Automate Pro is, especially with large.
quality focused, I'm gonna call 'em,
or quality oriented organizations.
So you, you've got the Rolls Royce of
the world, the Toyotas, those kinds of,
where quality is inbred in their, brand.
but also then you've got the,
organizations where quality
is, you know, is not an option.
So highly regulated organizations,
they have to follow strict processes
around testing and verification
of any change they make to
their systems, their platforms.
And that includes ServiceNow.
CJ: so what about quality
for the rest of us, right?
Like, um, you mentioned
folks like Toyota, right?
And they're just world renowned
for their commitment to quality.
They.
Like literally invented
a framework, right?
Um, that the f that a lot of
folks have adopted, um, because
they've been so really good at it.
Then you have like the other folks
who like pharmaceutical companies
and such that are regulated and so
they need to have this validation
from point to point to point, right?
And, and that's not an option either.
But then there are the rest
of us who d maybe don't fit
into either of those buckets.
Maybe our management doesn't
necessarily, want or value like the
Toyota letter level of quality and
they aren't government regulated.
Like, how do, how do we get that le
that same level of quality, especially
in something like ServiceNow.
Paul: Yeah, I mean, I think it's,
it's equally a problem, right?
No one wants to be spending money on
testing, um, when they don't need to be.
Everyone's looking for more efficient
ways of doing things, especially at
the moment, the macroeconomic climate.
So we've gotta do more with the people
that we've got, not everybody's, you know,
has a budget to, get more resource in.
So we need to be more
efficient and effective.
So, The, the conversation with those
sorts of organizations is, well, look,
you've got a team of five people or
10 people, or wherever it is, and
you want to be getting the maximum
amount of those people as possible.
What you don't want your developers
doing in that situation, and we know
that especially ServiceNow at the
moment to ServiceNow developers are,
are scarce and they're high cost.
The rates are rising,
you know, all the time.
So you want those guys,
those skilled guys to be.
Making configuration changes,
configuring new modules, bringing
out the real power from ServiceNow.
What you don't want those guys
doing is writing some code.
in tools like atf, which need, you
know, I think generally accepted,
you need to be quite a competent
developer to be able to use.
So really maximizing the
efficiency is the, sound bite
for those sorts of organizations.
Duke: I just wanna go over
one thing that's just, it
kind of keeps me up at night.
And it's not just the, the
efficiency of it, right?
Or how many, like how much
extra oomph can I get per person
who's focused on the testing?
It's just how bad is it in the trenches?
Like we have to, we have to
upgrade basically twice a year.
Right?
This platform keeps growing
horizontally, there's always some
new process module rolling on.
There's always some new or trialed out
tech that we need to like move to or think
about moving to, and so you've got that.
Twice a year and your stakeholders
are all across the organization.
So it's not like, it's not just,
okay, hey, it, who's probably used
to like stopping whatever they're
doing and testing something.
Paul: Yeah.
Duke: But can you do that for hr?
Can you do that for SecOps?
Can you do that for,
facilities management?
Paul: Yeah,
Duke: do that to your finance department?
Like they're in the
middle of close, right?
They're in the middle of financial close
for the organization and you're like, Hey
guys, you gotta stop for 10 days and like
Paul: yeah,
Duke: test your stuff
like, How did we get here?
Paul: this is the problem, isn't it?
ServiceNow has been so successful
now that it's rolling out, as you
say, across the organization and
everybody's jumping on and wanting
the, you know, the latest module
that fixes their enterprise workflow
problems for their functional area.
And that's fantastic.
But what that's brought with it, as you
say, is the increase in the potential for
things to go really wrong in a bad way.
brilliant example, Rob, is the, we
had a customer who, they had the HR
module and they tweaked an ACR rule,
nothing to do with the HCR HR module,
or so they thought they tweaked
this ACL rule, and it blew up HR.
And of course Monday morning when
it all went wrong, the head of
HR was jumping up and down and
saying, what the hell is going on?
ServiceNow's not working.
, and everybody was, you know, saying,
well, we haven't changed anything.
It, it should all be working.
And of course, it's the potential
for knock on impact across those
functional areas now, which is increase
every time we roll out a new module.
That's the, the risk increases.
Duke: can I just say a
couple more things that just.
Again, they keep me up at night
and I'm hoping you got an answer.
For us, this idea that
what we build is invisible.
It's not like we're manufacturing cars
and we can like look at the car and say,
what's that thing sticking out the side?
Like that's not supposed to be there.
Paul: Yeah.
Duke: there's such visibility
problems to the things that we build.
And the second thing is that our
consumer, who I would say a lot of the
ecosystem expects the consumer is kind of.
Very responsible for their
part of the testing, right?
So, oh, how did this
get all the way to prod?
Well, maybe you didn't test as much.
And they're like, how are they?
It's not their job.
Paul: Yeah.
Duke: They know what their job is.
This is just like a tool about the job,
and they're not the tools manufacturer.
And again, the visibility,
visibility problem.
So you can almost see why things
aren't documented as well, right?
Paul: Yeah.
Yeah, I mean the, the, the visibility
thing is, is a really interesting
one, and that's why, you know, our
approach to testing is that the system
should be tested in a way that will.
As closely as possible represent
how the user's gonna use it.
I always use, I always call it
the Monday morning test, right?
you are gonna make some changes.
You put a new release in on a
weekend, on a Monday morning when
somebody goes in and raises a.
Critical security incident at
nine o'clock on a Monday morning.
They need to be able to raise
that if the system hasn't been
tested in the exact same way as
that, US will do that on a Monday.
There's a potential that it could go wrong
and there'd be egg on the face of, you
know, a lot of people if that happens.
So that, that visibility of, and the
ability to be able to test exactly like
the end user is really, really important.
I think that's the first thing.
The second thing is you're absolutely
right about, the business are,
they're, these are busy people, right?
They're, they're busy running the
business, um, making their, their
functional areas productive as possible.
They haven't got the time to spend a week
testing, user acceptance, testing a new
release, or a, an upgrade of service.
Now, they just, they just want it to work.
So, you know, we've
tried to build in tools.
Inside of Automate Pro that help
those people be able to verify that
their Monday morning process is still
gonna work, but without having to
spend hours and hours or, days at the
keyboard making sure it's gonna work.
CJ: Yeah.
So that's a, that is a very
good, and, and I think very, um,
succinct value message, right?
For Automate Pro.
cuz when I think about testing, I
think about a part of the project
that is often under-resourced, right?
And often, the last thing to be done and
therefore the first thing to be squeezed.
Paul: Yeah, totally.
I spent many years of my career as
a project manager, and the number of
times I had to go to the, the, the QA
manager in, uh, in my project and say,
Hey guys, uh, we're, we are running
over a little bit on the development,
can you squeeze your testing into,
you know, a week rather than two?
it's the thing that gives, isn't it?
in a project, it's the thing
that can get condensed, and that
means that you're taking risk.
You know, at the end of the
day, that's what it's about.
And you don't really want to be
doing that, and you can't be doing
that in these, you know, large
organizations, cross-functional areas.
ServiceNow's come business critical.
Now, Hannah, haven't we, as you
know, let's face it, it's, it
used to be an IT help desk tool.
Service portal.
if your mouse broke, you needed
a new one, you'd request it.
It's not like that anymore.
You know, businesses are running
their, enterprise workflow,
they're ordered, the cash processes
are engineered on service now.
It's critical.
CJ: so that's a good point, ServiceNow
is becoming business critical.
I like that.
Um, because especially when I started,
it wasn't acknowledged as such.
I.
And then after you built, say like change
management on it, and change management
was rigorously enforced, then you'd start
to see where the business would be like,
Hey, this thing actually can't go down.
You actually need to put the
change management system through
change management processes
if you want to upgrade it.
Right.
And you know, and now like
there's obviously so much more.
That ServiceNow is running, uh,
especially horizontally, with all the
different verticals that are, that are
out there now, that the business can't
afford that downtime for ServiceNow.
And
Paul: yeah, and, and you know, crucial
part of change management, as we
all know, is testing verification.
You know, so, you know, as soon as
a change goes to the change board,
the first thing they're going to
look at is what testing has been
done and what, has this change
affected anything else in the system?
and that ability to produce that
evidence, especially in heavily regulated
quality focused organizations, but not
just those that, you know, everyone
wants to know that their system is
not gonna be brought down by this
change that they're implementing.
And that's why Fraud Rank Pro, you
know, we weren't just thinking about,
let's automate the testing, make
that simple, easy, quick as possible,
uh, with a hundred percent coverage.
But also what are the outputs that
the change board need to be able to
look at when they're reviewing the
change and assessing the risk of that?
And they're gonna need documentation.
They wanna see the test plans,
they're gonna wanna see the results.
They're gonna wanna see what defects
were raised and how they were fixed.
They wanna see that UATs been, completed
and acceptable, and they wanna see
the documents have been updated.
So this is, you know, we were
thinking when we, when we had the
vision for Automat Pro, we had the
vision that it was gonna help all.
Team members within the delivery
process, not just testers,
CJ: Right, because you're saying it's
not, it is not enough just to test and
hit a checkbox that the testing was done.
You actually need the evidence
that the testing was completed.
Paul: right?
Duke: Corey, how many change controls
have you done where it's like test
plan, will you write it in the ch
the test plan and then maybe you
put in the work notes like, I tested
CJ: Yeah, pretty
Duke: it and that was it.
I just like, like broke
into a cold sweat here.
Thinking about, thinking about
like, cuz ServiceNow really.
I am sure there's someone over there, but
I like, I just don't know if somebody has
seriously thought about if this thing is
so successful and people start trusting
serious operational workflows with it,
Paul: Yeah.
Duke: let's put our life
sciences technology on this.
Let's put our, our manufacturing
safety mechanism stuff on this,
where eventually, some flows out
there are so important that they are
measured in lives lost per failure
Paul: it's happening, you know,
it's because it's a, it's a great
platform, So, it's becoming more of
the business processes, the critical
business processes are being run on it.
And that, that's why we are super
excited because the more critical
it gets, the more you need to test.
The more you need to assure yourself,
the more you need to have control
of the ServiceNow environment.
it worries me that ServiceNow instances
and update sets can be moved around
and, put in without, with very little
control of what's going on, what versions
of configurations, you know, in what
environment, you know, who put them
there, what evidence was there that
they're, we, that they actually work.
Have we verified that they work
in that new environment and we
haven't broken anything else?
Scares me.
Duke: there without trusting you?
You know what I mean?
Like that zero trust reassurance.
Like I don't want to have to
just trust that you did it.
I don't want to see evidence of it.
And I think evidence, like we've
talked about the scary bits
of testing and kind of why.
the status quo doesn't cut it.
but evidence I think is a great angle
into what you guys do, Paul, and before
we entirely screwed up the first recording
and got halfway through with that,
with the recording, you were mentioning
something about , quality controlled
organization has to even take screenshots.
Paul: Yeah, so if I think back
to my first career, was an an
analyst programmer for investment
company and we were testing then a.
Pretty much in the same way as I see
companies still test today, and that
is Word documents of the test script X,
Excel spreadsheets of the R, the output
outcome of the tests with, you know,
defects tracked in X Excel spreadsheets.
This is still being done today.
You know, it staggers me that we
walk into organizations and this
kind of thing is still going on.
Yes, those things might be, you know,
there's Word documents and Excel is maybe
stored in Agile or something like that,
but you know, this is still going on.
We haven't really moved forward
and the organizations that we.
Typically talked to are the large,
heavily regulated or, you know,
quality focused organizations.
And they, they have really strict
requirements for the, for example,
the screenshots have to, in certain
organizations to meet regulations,
they have to have a u r URL at the top
on the screenshot, and they have to
have a date timestamp at the bottom.
And the reason for that is because what
they don't want is people, Being able
to go into paint and sort of adjust a
screenshot and take it two weeks after the
test cuz they forgot the, you know, they
should have done that step of the test.
These have to be, rigorously controlled,
in an environment where you can't go in
and tamper and just squirt a screenshot in
just the last minute cause you forgot it.
And the requirements are really strict.
these are the kinds of levels of
rigor that these organizations need.
To meet their regulatory requirements.
CJ: and just following up on that.
Right.
Cuz I find that fascinating.
how many of these organizations
right, are tracking the, the
resources needed to make that happen?
And like, what that spend looks like
and as a percentage of, of maybe
their total tech spend or their
total, total, uh, ServiceNow spend.
Right?
Like, it, it sounds like to me, in
order to do that effectively, you need
to devote a significant portion of your
ServiceNow team to just that action.
Paul: Yeah, I, I mean, I think that's
absolutely the case and, and what startles
me a bit is that that's become acceptable,
that, large teams of people and need to be
brought together, especially for upgrades.
I.
And we've got a couple of
organizations that we work with.
They spend three months, you
know, sometimes three months
more with a, a large team.
We're talking, 20, 30 people.
Often it's provided by a
ServiceNow provider as well.
so they're, you know, these
aren't, Low cost resources.
These are expensive resources.
They're brought together.
, all the focuses on upgrades.
I think organizations are starting to
realize, especially now that Automate
Pro, you know, is starting to, grow
and get a visibility in the market, I
think people are starting to question.
the spend on upgrades is too high.
That money could be better deployed
on, rolling out new upgrades of,
modules of service now, or, increasing
the usage in certain areas and
getting more value from the platform.
It shouldn't be money spent just keeping
up to date on the, the latest version.
That's, not good spend.
CJ: that's one of the things that folks
look at, when you start talking about
testing because they slot testing in as
like a maintenance kind of function and
they slot development in, it's like the
new and pretty, how can we get the next
feature that is gonna create that value?
But that, uh, sometimes I don't
think that they really realize
that testing is actually a really
huge value creator as well.
Paul: Yeah, absolutely.
it's interesting to see with customers
that are struggling with upgrades.
I was talking to a customer the
other day and they said the great
thing about Automate Pro is.
Now that we have confidence that we can
do upgrades at the click of a button, we
will now move to twice a yearly upgrades.
They were only doing once a year.
Not out of choice, but because the
whole damn thing was so painful and
extraordinary, resource hungry and
costly, that was almost enforced on them.
They were so exhausted by the upgrade
process that they did one year Now.
They're gonna move to two a year
and that will mean they can jump on
the new modules that Service Now.
I mean, they were, they were
going to knowledge events
and going, that's fantastic.
New module.
But we are not on that version.
You know, we're not gonna be on
that version for a year and a half,
so we can't take advantage of it.
So, you know, that's when
testing becomes a value add.
If you can test and upgrade
seamlessly and quickly, then you
can, get the value out the platform.
Duke: So we know that it's, it's
something that's gotta be done.
The more often you can
get it done, the better.
it's gotta be done thoroughly.
But how do you take the
effort out of the system?
Paul: this is the big problem
especially with automated
testing, , automated testing's
been around for quite a while now.
And what we wanted to do was to
solve some of the fundamental
problems with automated testing.
And those typically are not around
the initial build of the tests.
You know, you'll see a lot of
systems available, commercially that.
Have you believed that you can create
tests, , in, a matter of seconds?
They're typically kind of
click and record stuff.
I dunno whether you've seen those.
You, you know, you open up
service now and you say, right,
I'm gonna record a test now.
And you start filling in the form and
it sort of tracks what you're doing.
And then, oh, there's your,
there's your test script.
Uh, that all looks great until
ServiceNow come along and change the ui.
You know, and they're great.
A great example of that was
the next experience, right?
So if you've created your test using
that click and record method, Every
single one of those tests is gonna break
when you move to the next experience
So we wanted to solve that problem.
We didn't like that.
We don't even have click
and record actually.
And because of that very reason, it
looks great, but it's not robust.
And that's the biggest
problem with test automation.
It's not the initial creation,
it's the maintenance.
You've gotta have a system whereby
if ServiceNow upgrades their ui,
those tests are still gonna work.
So that, you know, any defect
that's raised is not related to your
script being out of date or wrong.
but it's actually a genuine defect.
in the world of testing
that's called test rot.
I dunno whether you've, come across
that phrase, but it's, it's basically
like the decay of your tests over time.
CJ: I love that turn right test rot.
Paul: Yeah.
CJ: might be a nice band name.
Um, but, but one, of the things that
I really just got from that is you
don't really want your testing to, to
also become like a maintenance sink.
Right.
Like, like you're, like, you're
implementing testing to reduce the amount
of time or automated testing, right?
You're implementing automated testing
to reduce the amount of time that
your testing takes, but then you need
to test and maintain the testing.
That's reducing the testing
and, you know what I mean?
Paul: Yeah.
CJ: so, how does Automate
Pro like help us with that?
Paul: I I totally get that.
And it was interesting, one of the
projects I was worked on a few years
ago before Auto Automat Pro I called
them out and I said, look, you've got a
project to test your project, you know,
You've got an entire other project just
testing, you know, test automation and
there was code, and the code was under
code control and config management and
it had to go through a release process.
I was like, oh my God, you've
created a whole project here.
So anyway, putting that to one side so
that the approach that we've taken is to.
make it as simple as possible to
update the tests in line with the
configuration changes that you're making.
and you've gotta do that, there's no
getting away from the fact that you've
got to keep your tests in line, you know?
But, we try and make that
as simple as possible.
And the, the way that we've made
that as simple as possible is, is
with something called model blocks.
and these are reusable components, They're
like, almost like procedures in, in code.
So that you're not, creating the
same, test over and over again.
you've got a block of, of tests
and that block may be used in, you
know, a hundred different tests.
Let's say it's, you know, how you navigate
to a particular part of the service portal
or something that would be a model block,
and you'd reuse that model block over and
over in different tests and navigate into
the portal and get to certain places.
Now, if the navigation changes, and this
happens a lot, we find with our customers.
They might change the, top level
menu structure of their portal.
They might put another
layer in or, rejig it.
So in traditional sort of test automation,
you'd have to go into every one of
those hundred tests and go and amend
that to, you know, to change it, to
follow the, new navigation and automate.
Yeah, all for it.
I mean, it's horrendous.
And, the same we've heard, in atf because
there's no way of doing this in atf.
So you've gotta go in a hundred and
as you say, that then becomes bigger
than the actual change you were making.
You know, that change to the navigation,
I don't know, I'm not a developer,
but let's say it's half a day's work,
changing a hundred test scripts, that
might be two or three days work, I don't
CJ: right.
Paul: so.
You know, in Automate Pro, you go
into that model block, you make that
one change once you test it, and then
that affects, that ripples through, if
you like, all those a hundred tests.
So, you know, what we've tried to
do is bring new best practice and
innovation into this world of test
automation and solve these problems.
if the tests aren't up to date, they're
no use, and, you know, so that, that was a
critical problem that we wanted to solve.
CJ: so it sounds like to automate
pros to service now for testing.
Paul: Yeah.
Yeah.
we're a really innovative company.
We want to, you know, we
thought about these problems.
it's hard for us cuz people
see click and record and they
say, oh yeah, that looks good.
That looks really easy,
looks great on a sales demo.
in reality it's really not very good.
So,
Duke: Paul, there's, one thing that
I was super blown away by with the
video that we did, is that if you're
careful enough, you can hit two birds
with one stone in a lot of ways.
So can you talk a little bit about.
automate pro as software
delivery, not just testing.
Paul: Yeah.
Wayne is my business partner.
he's worked in the IT delivering projects
just like me for, you know, 30 odd years.
and we've involved, because we've done
multiple roles throughout our careers,
we've done pretty much everything you
do in the software delivery lifecycle.
Our philosophy around testing is that
you should test as the end user is gonna
use the system on a Monday morning.
Right?
So almost like.
Use cases, user scenarios, and it
follows the process, the user will,
follow through, on a Monday morning.
Now, if you take that approach to building
your test, not only does that make sure
that on a Monday morning it's gonna work
for your user, but what we realized was
we are also capturing the screenshots as
we went through that process step by step.
When you come to create a user
guide or a process guide or a
training guide, Of that process.
What do you need?
Well, you need step by step going
through each step of the process, and
you're probably gonna need a screenshot
of what it looks like along the way.
And you need a description
of what you're doing well.
Okay, so if we take what we've done from
the test, the output of the testing,
and we repurpose that, so we've got
a clever function, which basically.
takes that output from the test
execution, all the screenshots, all
of the descriptions, all of the steps.
Recasts that in the form of a user guide
so that turns into a knowledge-based
article, step-by-step instructions.
Hey, Presto, you've just created yourself
a training guide, user guide, process,
document, whatever you want to call it.
And it's branded.
You can change the colors.
It's got a contents page,
you know, all the stuff.
Now, I used to be a business analyst
in my, one of my roles years ago,
and producing user guys used to be a
completely separate activity from testing.
And you would open up Word
and what would you do?
You'd go into, ServiceNow.
You used to grab a screenshot,
you'd put it in Word, you write some
text around it, grab the next one.
So we are saving, I dunno, days.
I mean, I used to produce user guides.
I used to take.
two to five days to create,
a decent user guide.
You can do that in Automat Pro in a,
few seconds with a click, on your mouse.
the great thing about that as well,
going back to the test rot thing,
you also got user guide rot, So
as soon as you Yeah, I like that.
I just made that up.
Um, if you, you know, as soon
as you change the system, you're
at a field onto a catalog item.
You, what's happened is you user guide
is how date that instant that's done.
So, this stops that because you've
updated the test to test that and
you field on the catalog item, press
the button, and you user guide is
updated with all the new screenshots.
So, you know, it's killing two birds with
one stone is a great way of looking at it.
we are trying to repurpose the
information as many times as possible.
CJ: so tell me you love developers without
telling me you love developers, right?
Like that's just what I heard.
Paul: I mean, the thing is
developers, are, you know,
absolutely key in all of this.
And what we want to be doing is
making them as efficient as possible.
So we all know ServiceNow
developers at the moment.
they're scarce, right?
And everyone's chasing after
the same set of developers.
Uh, and that makes them high cost.
I mean, I, I saw this way back in the
eighties with sap, uh, resource where the,
you know, the, the rates were ridiculous.
And the, I can see the same thing
happening with, with ServiceNow.
So what we've gotta do is make sure
those developers are doing what they're.
Niche skillset is, and that is
configuring ServiceNow, introducing
new modules, making sure that we
are using it in the best way, you
know, making it efficient code.
And what we don't want those
guys doing is writing tests.
We don't want 'em creating documentation.
We want to create those, you know,
take those sort of non-value added
activities as much as possible.
I think I saw a stat recently.
That about 30% of a developer's time is
actually spent developing code and 70%
is on sort of non-value added moving
update sets through environments.
You know, trying to, handle all of
that deployment stuff and things.
So we, one of our aims is to make
that 30% move that dial 30% to size.
I know 70%, 80% get them really
efficient in doing what they're great at.
Duke: I think on the documentation
side, we're not gonna get much
more efficiency because I just
don't think it's being done right.
I think it's a fraction of the
ecosystem that does documentation,
but here we are, how many years
have I ranted about it, Corey?
How many years?
And it's a button away.
It's a button away.
CJ: the value, right?
The value here, duke,
right, is just immense.
Um, from a lot of different
perspectives, right?
Push button documentation, oh my God,
Push button, test, deployment, oh my God.
the ability to scale that and
to scale the updates on that.
Oh my God.
And, and look, this is last piece, right?
that management doesn't really care
about, but I'm, I'm still in the
trenches and I absolutely love is
that you're gonna take all the things
that I don't want to be doing and do
them in a automated fashion, right?
Like, I don't want to be
writing documentation, right?
This, it's absolutely necessary.
So I do it I hate moving update sets
from instance to instance, right?
Like, I hate running the test
and writing the test, right?
Like all of that stuff.
I don't wanna do any of that.
and you're telling me not only
can automate pro do that for me
right now, I don't have to do it,
which is great, but it's gonna
do it better than I could anyway.
Paul: absolutely.
Developers are developers because
you love developing code, right?
You don't love doing, you don't
love doing documentation and,
moving up there, that's not why.
You know, we've got, we, we've got
developers, uh, in our organization
obviously developing Automate Pro,
and they wanna be writing the code,
and doing clever, you know, clever
things with the configuration.
this is the way that we see the world.
Let's get everybody in the
software delivery lifecycle
involved with ServiceNow.
This.
Remove the mundane, repetitive, the manual
activities make everybody more efficient.
and as a result of that, everyone
will be happier and the ServiceNow
platform's gonna be high quality.
It's gonna make the users more happy
cuz there's less defects in it.
So this is, we're trying to aim for.
Duke: One last thing, Paul, you, you
get HR shipped with your instance,
but the second you start making your
own configurations to it, you've
essentially got like HR 1.01, right?
Paul: Right.
Yeah.
Duke: we have things going, development,
going in parallel, some things,
reaching, prod before other things,
even though they're started later.
And were you mentioning that Automate
Pro has something to help with that?
with the actual deployment of the work?
Paul: Yeah, we have, and, and
really it stems back to fundamental
realization that we, we, uh, arrived at.
So we under, we are looking at
the ServiceNow environment, the
different instances, development,
test, staging, you know, production.
And what's really interesting
is that there's no real concept
in ServiceNow of the release.
To production route, The instances don't
know about each other and they don't know
their purpose and they don't know where
they sit in that route to production.
So what we've done as part of our
auto deploy module, which essentially
moves update sets from one environment
to another, um, automatically,
so you don't have to mess around
with, you know, moving updates.
That's manually, but more than
just doing that kind of a bit of
rpa, really moving things around.
It's the control around that,
and it's the understanding of
what products you are creating.
So we have the, the concept of
products, so that might be , hr,
you could define as a product.
And then you've got the
concept of product versions.
So just as you say, as soon as
you install version one of HR
that's in Dev, you configure it.
We understand that that configuration now
is version 1.1 of hr and we un understand
the update sets that make that up.
And we also of course link that
to the test that verifies what.
Means 1.1 works, you know, what
does good look like for version 1.1?
And then we understand, because we're
automatically moving that product
through the different environments,
we understand where each of those
instances is in terms of the version.
So we've got version 1.1 on dev.
We've got version one on test, and
we've got nothing in production.
And as we gradually make these incremental
changes, we're controlling those.
Versions of those products and we know
which version of which product is on what
instance and whether it works cuz we've
also got the testing piece coming in.
And importantly, we've also got, which
is the kind of nirvana situation.
We've also got the linkage
back to the requirement.
The original requirement, so we can
track that requirement is tested
by this, it's in this release, it's
in this instance, and we know where
everything is and in full control.
Any organization that is gonna
be using ServiceNow as a business
critical or enterprise platform is
gonna need that kind of level of
control across all these environments.
CJ: Wow.
So sometimes I feel like, you know,
the, the proper question to ask is
what, what doesn't auto automate pro do?
Paul: Doesn't make a cup of tea on.
CJ: Yeah, I mean, there's some
smart teapots out there now, right?
I mean, we could probably figure that out,
Paul: There's organizations as customers
of ours that are realizing that what they
thought was good was actually not good.
They were putting up with, good enough.
and they're, they're really
starting to see that.
I mean, we're, we are
getting stats back now of.
90% cost savings on upgrades I think
the number is 72% more test coverage.
We've got 83% reduction in team size.
And so these, you know, we
were talking earlier about the
team size needed for testing.
You can reduce that by 83% as this
is big, big numbers start to come in.
CJ: this is paying for itself.
Paul: Yeah, absolutely.
I mean, the r there are ROI is simple
calculation simp because of the, you
know, the sorts of costs involved.
and we haven't in factored in which you
should do really in a full business case,
is the risk reduction side of things.
So, you know, as we talked about
before, if we go, if ServiceNow
becomes business critical, if it's
frontline, I think Coca-Cola actually
use ServiceNow for their B2C app.
Uh, I understand.
So you can actually go on your mobile
phone now and buy a crate of Coca-Cola
and have it delivered to your door.
You know that if that goes wrong.
That is, you know, as customer
impacting and that's gonna
affect Coca-Cola's reputation.
So, we need to make sure
those sorts of things work.
So you can start the factor in,
well what's the risk to reputation
if that app is not available, for
two hours while they fix a bug that
was introduced in the new release.
You know, just on a cost
efficiency and time saving.
bases, it stacks up.
If you're factor in things
like risk reduction, then
you know it's a no-brainer.
Duke: okay, and this is why I had to
have you on the show, Paul, is just.
It's a miracle app as
far as I'm concerned.
In the ServiceNow space.
It's just talking about if I'm
regulated, it's easy passes on
my regulations, even if I'm not
regulated, but I'm quality conscious.
It's push button whenever I
want, receive my test results.
It's ridiculous savings of labor,
which means I can push this app even
wider, and as the product owner, I
can get more, victories under my belt
so I can move on to my next thing.
Paul: Yeah.
Duke: then you finally get Robert
to shut up for two seconds about
the doom and gloom if you don't have
documentation about what you've built.
it checks all the boxes.
It checks all the boxes.
So Paul, if somebody listened to this
episode and they wanna like, find out
more, how would they go ahead and do that?
, and we'll still have links
in the description below.
Everybody take a shot.
we will have a link in the description
below for how to contact Automate Pro.
But what else could they do, Paul?
Paul: Yeah, , absolutely.
I, I mean, I don't mind
people reaching out to me.
I'd love to speak about this stuff.
You know, it's my, it is my baby.
So, reach out to me in LinkedIn.
happy to have a conversation.
Obviously there's a website,
www automate pro.com.
loads of information on there.
There's a contact button.
the guys who were a super
friendly team, we're all like me.
I would say, and friendly.
we love ServiceNow.
We love everything about ServiceNow.
Hit us up on the, the website.
We'll get you sorted.
let's have a conversation about it.
Duke: All right, Paul, final War is yours.
Paul: Um, oh, you caught
me out there, Rob.
Duke: My final
CJ: Was that.
Duke: episodes in.
Paul: It's brilliant.
No, no.
Thanks.
Uh, thanks Aaron.
I'm Rob.
Super, uh, great conversation.
Love talking about this stuff as I say.
So, uh, anytime you want me on
again, happy to, happy to come in.
Duke: Pleasure was ours.
Paul.
Thank you so much.
CJ: Thanks Paul.