. 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.