English titulky

← From Go to Whoa: How to Make a Difference with JIRA Service Desk

Získať kód na vloženie
1 Language

Ukazujem Revíziu 18 vytvorenú 05/20/2016 od khendricks.

  1. Welcome to my session.
  2. I came to summit last year
  3. and I talked about how
    we support and build
  4. doing all the ships using JIRA
  5. and at that time I had this burning thing
    in the back of my head
  6. about what we were going to do
  7. replacing our own
    existing service desk
  8. and I have been looking forward
    to giving this talk for months
  9. and what I want to do is
    take you through our story
  10. so that next year,
    when I come back to summit,
  11. you'll be giving your story.
  12. How is it going to work?
  13. It's going to start off
    with where we were,
  14. how we had to get there to go and fix it,
  15. what I learned over that time
  16. and then, finally, the results.
  17. So, this is where we were 12 months ago.
  18. That was the main entry portal
    to work with corporate IT and HR.
  19. That portal was done in 2007,
  20. and as you can tell,
    it's not very current in its design,
  21. and that's exactly where we were
    for many, many years.
  22. That's what our customers saw.
  23. This is what our agents dealt with.
  24. And our agents
    had this complicated system.
  25. It was OK, it worked, did the job
  26. but that's outdated interaction
    for agents and customers.
  27. That cost us $85,000 a year
    in licensing alone. Alright.
  28. If you want to be stabbing yourself
    with a fork in the eye,
  29. that's the cost to do it.
  30. (laughter)
  31. So there were lots of workarounds in place.
  32. The true cost was actually more than that.
  33. But that was OK, everyone said
    it is working,
  34. so why change it?
  35. Does this sound like you?
  36. So who here at the moment
    has got a system like that?
  37. Put your hands up.
  38. Yep, who's thinking
    about doing JIRA Service Desk?
  39. Yep, alright, good.
    So let's begin.
  40. We could have fixed that problem,
    but it was working.
  41. Our customers didn't really complain.
  42. That was their way to work with HR and IT.
  43. They'd done it since 2007, no problems.
  44. We in IT said, "well,
    of all the other things we'd be doing,
  45. we don't really need to fix it",
  46. so we just kept pressing
    snooze on the problem,
  47. snooze on the problem
    time and time again.
  48. We weren't going to fix it
    because
  49. there were other business things
    we could fix instead.
  50. But --
    and here's the big but --
  51. it all came to a screaming halt one day
  52. when we did had a problem with the system.
  53. It wasn't compatible with the new browser
  54. so we ring up our services partner
    like we've always done before,
  55. the number is disconnected.
  56. The reason for this is that
    that product we're using,
  57. end of life, out of warranty,
    everything about it was just dead.
  58. It was absolutely dead end.
  59. And we kind of looked at it like
    "that's going to be a problem."
  60. These workarounds we had in place
    were getting expensive,
  61. so we decided that it was probably
    time to do something about it.
  62. That's when I was here
    at summit last year.
  63. So we did what we always do,
    and that is we go to market.
  64. So we went to market and we said well. We actually found out
  65. it was going to be
    pretty expensive to change it.
  66. We were looking somewhere in the realms
    of $400,000 to $700,000
  67. to fix this problem, licensing alone,
  68. so let's call that a million bucks
    by the time we implement it.
  69. Working at, say, 10% profit
  70. you're going to have to sell
    $10 million worth of product
  71. to pay for corporate IT's
    ticketing system.
  72. In summary, the executive summary,
    is that it is nuts!
  73. So people said: "the system
    isn't actually broken,
  74. so how many more workarounds
  75. can we put in place
    just to keep it going?"
  76. Because I don't necessarily
    want to go out
  77. and find that million bucks,
    and what are the requirements?
  78. Because it's just ticketing, alright?
  79. How hard can it be?
  80. So we have the tag line with BAE
    which is "Inspired Work"
  81. and we've got these three company values
  82. which are: Trusted, Innovative, and Bold.
  83. Now I was hearing we were going to market
  84. and we were looking
    at spending a million bucks.
  85. and it's going to take us
    12 months to do it
  86. and I was at summit here going--
  87. Alright, I'm going to have to look
    at the company values
  88. because I think we can do it
    for far less than that
  89. and we'll do it in JIRA Service Desk.
  90. We already use JIRA.
  91. We already use the product suite,
  92. so how hard can it be?
  93. Then I thought,
    what is my role in the company?
  94. At what point do I say,
    "I'm going to call you on this one.
  95. I think it's wrong, because my role
    is to provide the best outcome
  96. to not only our external customers,
  97. but our internal customers as well."
  98. So, as Barney would say,
    challenge accepted.
  99. As I went to our commercial people
  100. after coming from Summit last year
  101. and said, "look,
    I know you've gone to market.
  102. I know you've got this request for tender.
  103. How are we going to do in this with Atlassian?
    How can we make it work?
  104. Because Atlassian
    don't do request for tenders."
  105. and our partner is saying,
    "we can do something with you
  106. if you can get more information."
  107. So our commercial
    and procurement people said,
  108. "OK, you're under the same rules,
  109. so we've got three vendors
    that we're working with at the moment.
  110. You can prepare and do the pitch
    for JIRA Service Desk.
  111. And that's exactly what we did,
    so how hard can it be?
  112. Because it's just ticketing,
    we've got all the experience.
  113. I have a team of five who understand JIRA
  114. and its interactions.
  115. The worst I had to do was go
    and speak to all those people
  116. and ask them, "what do you really need?
  117. The requirement spec
    that was sent for quote?
  118. It looked about this long
    and it had things
  119. like "configuration management database",
  120. "how to manage problem records",
    and "how to do incidents"
  121. but it was like of all those things
  122. that's adding up
    to that million dollars implementation,
  123. what do you really need?
  124. Let's not have the Ferrari
    because that's quite expensive.
  125. Let's say if I was to replace this,
    sizable trunk was achievable.
  126. What do you really need?
  127. I put together the pitch.
    I had three hours.
  128. That's what the external suppliers got
  129. so I had the exact same time.
  130. I actually used the JIRA Cloud
    to put it together
  131. and pitched it to the review team.
  132. It was the same review panel members
  133. who had done the other
    ITSM tools
  134. and the result of that
    was five out of six said,
  135. "JIRA Service Desk
    actually does make sense,
  136. because it's going to interact
    with our development team.
  137. So people put a service request in
    for something
  138. in our finance system
    that's going to result in a task
  139. that's going to be given
    to a development team to fix something.
  140. That goes on its Agile board.
    That makes sense."
  141. We said, "It's going to use
    all the things we already got,
  142. so why go and buy
    an extra reporting system?
  143. We'll use the reporting service
    we've already got.
  144. We'll use existing databases
    we've already got.
  145. We'll add some interactions
    with our Oracle ERP system.
  146. So what we're going to do is take all the existing systems
    we have at the moment,
  147. best of breed, put JIRA
    as the ticketing solution,
  148. and then work with those external systems.
  149. So, then it was OK,
  150. but be careful what you wish for,
    because then they said "yes".
  151. That sixth person who was a holdout
    on that team actually didn't say "no".
  152. They just said "maybe" because
    we have external
  153. reporting requirements
    on things like change requests,
  154. and I hadn't demonstrated that enough.
  155. So I got another week,
    go back into reporting, demonstrate it
  156. and then it was six out of six.
  157. So then we decided, how
    are we going to do this thing?
  158. Because my team is supporting
    my internal customers
  159. and I don't want to draw them away
    for many, many months
  160. to do an ITSM internal thing,
    so what we said is,
  161. "OK, so let's do...we'll do it using Agile."
  162. We had this thing called OC1.
  163. OC1 is Operational Capability One.
  164. What are the things
    you really, really need
  165. for day one to go live?
  166. That's a smaller chunk HR
    so that we'll do that one first.
  167. Then, we'll do IM&T
    which is your corporate IT
  168. and that was our OC1.
  169. No more than two weeks after HR.
    Why is that important?
  170. Because you wouldn't believe the
    amount of interactions
  171. HR and IT have with each other
  172. and you don't want them
    on separate systems for too long.
  173. Last year when Vista Print gave their demo
  174. a found the phone number for
    Vista Print gave her a call,
  175. said "Tell me what you would do better."
  176. The number one thing was this:
    don't have people on split systems.
  177. Things like you have a new hire
    come into your company,
  178. they need to have
    their account created, IT does that.
  179. Those are the type of interactions
    that happen across there.
  180. Our sprint cycle was two weeks,
  181. that's why we go to the two weeks as well.
  182. Then, we're going to break stuff.
  183. Don't be under any illusion
    that you won't break things.
  184. You will break things, so OC2
    that's where you're going to fix that.
  185. Then it was just iterations after that,
  186. so we're in this continuous
    improvement cycle now
  187. but I always set a really low
    expectation for people saying,
  188. "I'm going to break stuff,
    because since 2007 to now
  189. there will be somebody's
    written something custom,
  190. there's a system
    that was undocumented."
  191. We're going to break stuff,
    but letting people know
  192. that there's an avenue
    to get that corrected in OC2
  193. gives people lots of confidence.
  194. They'll say I'll go
    without it for a couple of weeks
  195. knowing that you're going
    to fix it next time.
  196. But one thing that
    really won people over was,
  197. "we're not going to fix just IT
    and HR's problems.
  198. We're actually going to fix
    other problems around the company."
  199. So things like we didn't have
    Single Sign on
  200. and we didn't have Crowd
    and I said as part of my proposal
  201. we're going to install Crowd.
  202. We'll hook that to the active directory,
  203. and then we're going to hook up
    Fisheye, Crucible,
  204. and Apache Subversion, all those things.
  205. So that those dollars that you're spending
  206. to fix IT's ticketing problem
  207. are actually going to fix
    developers' problems.
  208. Fix things that the business cares about
  209. and that makes your pitch
    much, much better.
  210. This is where I talk about:
  211. Fix the things, tell people
    other things it's going to do.
  212. As part of this we included installing Crowd
  213. but also HR had a list of things
    that they wanted fixed as well,
  214. so people started to really look forward
  215. to when this implementation comes,
  216. I'm going to get a better user experience
  217. plus all those other burning things
    are going to get corrected too.
  218. So, how long is it going to take?
  219. Well, 5 Sprints
    is what we said we could do it in,
  220. and you've got to be realistic
    about what's going to be achievable
  221. and we had these two week sprints
    that we were going along
  222. and that was consistent with other teams.
  223. Other teams were working sprints too.
  224. We had to line up with a cutover date
  225. and that's going to be between
    the sprint for you and there.
  226. You don't want to do it during sprint.
  227. What we did then
    was break it down into epics
  228. so we had all of HR's
    Operational Capability One items,
  229. things like Incident Management
    had to work on day one.
  230. Request fulfillment and things
    like service requests
  231. and being able to buy laptops.
  232. You don't want to interfere with that,
    with the business.
  233. Knowledge management, so we said
    one of the big wins
  234. we're going to get
    is integrating our self-service
  235. so we said Knowledge Management
    had to be there.
  236. Change, there were some bits
    of change that had to happen
  237. because external reporting,
    so things like in change requests
  238. for modifications to your finance system.
  239. You'll need to report on those.
  240. They need to be there,
    and Problem Management.
  241. We also had some other systems
    that were outside of our team
  242. that we had to make sure
    they we're aware of.
  243. Things like automated
    software self service,
  244. access request systems
    that would use the API,
  245. they had to be available
    from day one as well,
  246. and that's pretty much
    how we broke it down.
  247. So that's the easy bit.
  248. All that planning and telling people
    what you're going to do,
  249. that's the easy bit.
  250. But we had to really create
    a persona about this.
  251. It wasn't just a technology system.
  252. This was going to make a big change
  253. in the way the business does work,
    so we had to start to say,
  254. "How are we going
    to tell people about that?"
  255. One of the things that happened
    at the time was
  256. "Why are we doing this?"
  257. We got somebody from corporate comms
  258. to come and join our team.
  259. I was like, "Well this is
    going to be a bit fuzzy,
  260. dancing through a field
    of poppies with this thing.
  261. What's going to happen?"
  262. And she created this image,
    and it was this one
  263. and it was "We're finally going
    to get rid of that old bus.
  264. We're going to stomp it out with JIRA
  265. and it was going to be a lookout,
  266. here comes JIRA Service Desk."
  267. So we marketed this change
    telling everyone this is coming.
  268. At our all hands meetings everyone knew about,
  269. JIRA Service Desk is coming,
  270. how are we going to fix it,
    what are we going to do?
  271. And Godzilla was the key to that.
  272. That's good at some levels but there
    are some people you've got to get to
  273. and they don't respond to that
    but they respond to that instead.
  274. We were removing being able
    to log by email
  275. and how many times have I told people that
  276. and said, "grumpy cat will tell you"
  277. and he can get past those, so yes,
  278. we gave him those sort of things.
  279. One thing we found is that we
    really needed to work out--
  280. people were going to tell us things
    that we didn't know about,
  281. so there were external systems
  282. and the things you're going to break.
  283. We found very early on,
    one of the first service desks
  284. you should create
    is for the implementation team.
  285. Start using what you're about to deploy,
  286. so we created a JIRA Service Desk
    implementation project
  287. that was the very first one in the portal.
  288. So people who wanted to know
    more about JIRA Service Desk
  289. would actually just go to the service desk
    and ask a question.
  290. Those questions became feedback
    like "that system over there,
  291. we've got to make sure
    we include that in the next sprint".
  292. But it meant that when we
    started to go to HR
  293. and start talking about
    what they need in their portal,
  294. and they had some feedback
    they thought of later on,
  295. they went and loaded it too,
    so they started to get very early on
  296. what the user experience
    was going to be like.
  297. So I can't stress this enough now:
  298. use the system you're going to use
  299. to deploy the system you're going to use.
  300. A lot of things like infrastructure
    changes when you add crowds
  301. was a big deal for us.
  302. And I was thinking one day,
    "I need five minutes' time
  303. from all these different people,
    from different business units
  304. or in different parts of active directory
  305. and in different use cases.
  306. How are you going to do it?
    Does anyone know what that is?
  307. Who's been to Australia or has seen it?
  308. This is a TimTam.
    TimTam is a chocolate biscuit.
  309. You would be surprised how much good will
  310. you can get with a TimTam.
  311. (laughter)
  312. I'm standing in our coffee
    line up at our cafe
  313. and I was thinking, "I need five minutes"
  314. and there was this line
    of people and I'm thinking,
  315. "If I bought everyone
    a coffee and a TimTam,
  316. I've got five minutes time."
  317. What we did, marketing the change.
  318. Took over our laptops,
    went over to the cafe,
  319. set up, had one person
    who was going to get coffees
  320. because once you're sitting down,
  321. you can't go anywhere,
    I've got you for five minutes.
  322. Another person was looking at how
  323. the calls were coming into the system.
  324. Was the automation working, and so
  325. we actually got a lot of customer insight
    from a bag of TimTams.
  326. $100, get 20 people in the morning
  327. and you actually start the test
    to see if the system's working.
  328. Does your portal make sense?
    Do the keywords make sense?
  329. I'm not quite sure what your equivalent here is,
  330. but TimTams, way to go.
  331. So that's been talking
    about how we got there
  332. but what does it look like?
    Well, this is it.
  333. As I mentioned at the bottom left
  334. there's our JIRA Service Desk
    Implementation Project.
  335. If you want to ask a question,
  336. you want to get in touch with the team,
  337. because a lot of people
    had these questions
  338. but they had spreadsheets
    that were tucked away,
  339. and if we knew about that,
    we could fix it before day one.
  340. Going live was going to be so important
  341. because we don't want to break stuff
  342. and you wouldn't believe what
    a difference it is, when you have--
  343. If you've used JIRA
    for software projects, that's fine,
  344. but if you've got customers
    who are expecting things
  345. like HR payroll processing,
    credit card acquittals
  346. and all those things,
    you can't break those on day one.
  347. So we made sure we got out there
    all the time saying,
  348. "Go and use the portal.
    Tell us what your problem is."
  349. So HR Service Desk was our day one,
  350. mainly because it's a slightly
    small chunk we could do.
  351. They was a team of about 40 people.
  352. They were doing, at the time,
    they told me 250 requests a week.
  353. Turns out it's 1,000, but that's OK.
  354. One thing we discovered with HR
    is that, while you might think
  355. HR Service Desk is just a group of people
  356. who just deal with the Service Desk,
  357. that goes all the way back through
    to things like payroll office.
  358. That was something we didn't consider,
  359. so when the 250 item,
    250 calls a week which was actually 1,000,
  360. they would actually print out
    the old calls they were working on,
  361. take them to payroll,
    and payroll would do things
  362. like changing people's reward
    or changing people's bonus,
  363. those sort of things.
  364. And we said "why
    don't we just include that
  365. so you don't have that anymore
  366. so you grab the call,
    and you push it to the pay office,
  367. they do it, it comes back,
    and the customer sees the whole lot.
  368. They're like, "Absolutely, let's do that!"
  369. So just be aware that HR
    is that whole iceberg thing,
  370. so just be careful.
  371. Then IT, so corporate IT was after that.
  372. If you work in corporate IT
    you want to get the one right,
  373. because you can't dodge these ones
  374. because they work next to you everyday
  375. and so we had a lot of people with IT
  376. who wanted to see this thing work,
  377. so really, really good to see
    that you're going to get people on early.
  378. One thing that sort of popped up
    that we would later accommodate
  379. was this thing called "Bright Ideas"
  380. which is business improvement,
  381. so on here you'll see
    "Business improvement HR and IT."
  382. We spent days deciding over these levels.
  383. Down the left hand side we did
    some access and purchase vaults.
  384. Those, we used some analytics and checked--
  385. What are people asking for?
    Access was the number one thing.
  386. So things like you want access to a system
  387. or you want access to a network drive,
  388. is the web locking get in your way?
  389. Those are the three things there
  390. that people mentioned time and time again.
  391. These are the things that Teams
    without Borders was telling us:
  392. What do you want to see there?
  393. Because there's no point
    in IT owning the portal.
  394. It's your customers that own it,
  395. and as part of our continuous improvement
  396. we come back and evaluate,
    are these things still appropriate?
  397. Have things changed?
  398. We also thought about--
  399. This is all well and good
    for once you've done your testing
  400. and people say
    "this is how I like it laid out"
  401. but how do they get
    in touch with you later on?
  402. So it's very important to say,
  403. "look, my request doesn't feature
    any of these.
  404. I've just got an idea
    that maybe you want to consider.
  405. So we had I just want to speak
    with someone
  406. or tell us an idea or improvement."
  407. Because this is a living thing.
    It's not a project you deliver
  408. and then you never come back to it again.
  409. It is a living, breathing thing.
  410. Over on the HR side,
    HR wanted three levels
  411. and they HR deals mostly
    with other HR people.
  412. And one of the areas they spent
    a lot of their time was actually
  413. this little three HR Only saying.
  414. Their number one thing
    was departmental supervisor changes,
  415. that lines and spans the control.
  416. Higher Duties Allowances,
  417. We had to spend a fair time
    just focusing on them
  418. because they said, "we just
    want it like the old system.
  419. It had one thing and then
    we did the categorization."
  420. But they didn't realize
    the potential they could now get
  421. and it's your job
    to give that best outcome
  422. is to tell them what this thing can do.
  423. This is an example of what we used to do
  424. so you go from that first slide
  425. and I'll show you
    what we had in the portal.
  426. It was sort of one text box,
    one summary, and that was it.
  427. We decided to build
    these things to show HR
  428. that one of the mandatory things
    you need for that type of request
  429. is to deal with that mindset
    of "we just have one request
  430. and we just filter it
    and send it to the right person."
  431. So you have to sort of guide them.
  432. You might know how JIRA works.
    That's really relevant to you,
  433. but HR, they didn't find it as simple
  434. as putting two and two together.
  435. So what went well?
  436. You can't get to everyone.
    Be under no illusion.
  437. So what we said is "OK,
    every team that we've got,
  438. we've got 30 teams,
    you've got to have a champion.
  439. Because we can't get to them,
    we're only a small team of five."
  440. So they now have champions
    that we had meetings with
  441. that said "this is what's coming,
    this is what we're thinking of.
  442. These are designs
    that have been made in the last week,"
  443. and they would take them
    back to the teams and then back to us.
  444. It's much easier to manage
    that sort of department champions
  445. than it is to measure a whole department.
  446. Demonstrate Early,
    we would often publish the link to people
  447. "this is what we're thinking.
    This is what it looks like this week."
  448. It would change, but our IT people
  449. like to just get in there
    and mess around with it.
  450. If we found any opportunity
    at any training session
  451. that had a five minute break,
    we'd talk about his service desk,
  452. his agent view, what do you think?
  453. So getting there early
    was key for most people,
  454. and certainly for HR,
    who at one point
  455. were actually really apprehensive
    about this change
  456. saying "you're talking about it
  457. and I haven't seen it, let's have a look."
  458. So we would often give people
    access to demonstration systems.
  459. Use it really, really early to get
    the feedback about how you're going
  460. because some people would sit back,
    they won't come and see you
  461. but if they can go and use the portal
    and set out to experience
  462. what a customer feels like,
    that's the way to do it.
  463. What will we do next time?
  464. HR is not a project organization.
  465. We were doing our sprints
    and our deliveries
  466. and everything was going really well,
  467. and we had a date locked in for HR
    which was June 1,
  468. and we'd been talking
    about that for months,
  469. and the day before they're like "stop."
  470. We're like "what?
    Everything's working fine.
  471. You've tested, it's fine."
    They're like "no, we're going to do
  472. a pay run because the pays
    go out next week."
  473. We're like "why didn't they
    tell us about this before?"
  474. Then they mentioned "you in IT
    have projects that you deliver,
  475. and that's how you work.
  476. We deal with the transactions
    of business,
  477. and we don't have people
    set aside for this project.
  478. They're doing this on top of things
    like payroll and bonuses,
  479. all those things are going,
    so they haven't been able
  480. to get to it this week
    because they're doing that."
  481. So we don't want to go
    with a half-baked system,
  482. so can you just slow down a little bit?"
  483. And it was like one day where
    I hadn't actually thought of that.
  484. I thought they
    had just given us resources.
  485. No, it was on top, so you just need
    to brief them more often,
  486. tell them when it's coming,
    make sure they're OK with it,
  487. they've got the resources to go with it.
  488. They don't care about the technology.
  489. They just want to know
    where the features are,
  490. so with our sprints
    we would start to tell them,
  491. "next week you'll get
    department supervisor changes.
  492. You're going to get
    some automation in payroll."
  493. That was the feature
    we had to do with them,
  494. but it meant that we had to
    have some automated testing,
  495. because again,
    they're not a project organization.
  496. We've changed something,
    we'd go back to ask them
  497. "Can you just check if this works."
    They're like,
  498. "well, we can't because we have
    a whole pile of stuff next week
  499. so you have to wait again,"
    so automated testing.
  500. Another thing that happened with this
    too was that we didn't upgrade
  501. and again, we've done upgrades
    in JIRA many,
  502. many times before, no problems
  503. and I did it on a Friday night
    and everything went fine.
  504. We did the upgrades, services went fine.
  505. On Monday morning I get this call
    and it's running like a pig
  506. and I'm like,
    "What are you talking about?
  507. We've done this before, nothing special,
  508. just a small version upgrade."
  509. We had two bugs
    that were actually introduced,
  510. massive difference in performance.
  511. So an issue went
    from 3 seconds to a minute
  512. and the portal was a bit sluggish.
    It was OK, but a bit sluggish.
  513. We didn't have the automated testing
    in place to test for those things
  514. and we spent a week
    trying to work out, was it us?
  515. And we spent a week and lastly
    we found out it was them.
  516. And the business is like
    "We need to get this fixed
  517. because the amount of people
    you're touching now is so much larger
  518. that it's not just
    the development community,
  519. it's everyone who's working,
    whether they're building ships
  520. or they're on the flat line,
    we need this fixed.
  521. A minute is a big problem."
  522. So definitely include automated testing.
  523. Whether that's the grinder scripts
  524. or something you do
    or if you've got some other testing suite,
  525. got to include that next time.
  526. Also, go to live date
    is before your training.
  527. We had a plan and had our sprints
  528. and we said, we're going to give
    training for all of our IT people
  529. between this week here,
    but the delivery date
  530. is actually out here, so that's OK.
  531. But people in the training course,
  532. things have changed a little bit
    since last week or yesterday
  533. and the key point was, actually,
    have it before your training.
  534. Do your training and give yourself
    a week after that
  535. to correct some things.
  536. We just thought we'd just do it
    at the same time.
  537. So certainly your go-live date
    is before your training.
  538. Consistent statuses --
  539. This is where
    I would say demonstrate early
  540. so just do the out-of-the-box things
    that actually work for you.
  541. In most cases, they probably will.
  542. We decided that "no, no, no.
    We know better.
  543. We'll change some statuses so that in HR
  544. the very first status is wait for triage
  545. and over in IT we have
    waiting on support."
  546. So our customers say, "Where
    in the workflow are those different
  547. because the status names are different,
  548. therefore they must have
    different workflows".
  549. So when you're implementing these projects,
  550. have consistent statuses for you customers
  551. so they understand where their thing is.
  552. And also confirm the HR use cases,
  553. When I talked about it, someone logs a
    call and then we just deal with it.
  554. No, actually show me what you're doing
  555. so take me through it,
    take me through the office.
  556. Show me how you
    actually deal with that call
  557. so that when someone asks
    for something to be changed on payroll,
  558. where does it go?
  559. What else is important?
  560. Single sign-on is important
    and we provide this.
  561. We use a plug-in to do this
    with [inaudible] single sign on plug-in
  562. so that when you open a browser
    it automatically
  563. logs you into Crowd
    which then automatically logs you
  564. into JIRA and JIRA Service Desk.
  565. I didn't think that
    was a big deal for Chrome.
  566. It didn't work in Chrome but we thought
    the standard browser is IE,
  567. that's where we have gotten our SOE.
  568. As long as it works at IE it's fine.
  569. We would go live and a flood of calls.
  570. Doesn't work in Chrome--
    alright,
  571. but Chrome's not
    standard operating environment.
  572. Doesn't matter, that really isn't important
  573. for people to get that to work.
  574. But customers said:
    "Now I have to log in.
  575. I didn't have to log in
    yesterday in the old system,
  576. so single sign-on is definitely important.
  577. Change control.
  578. Now that you're
    affecting everyone in the business,
  579. you need to have that
    really down pat and managed
  580. so that you will have a backlog of things
  581. that you want to include as improvements.
  582. How we do that now
    is we have a change board
  583. which one person from every service desk.
  584. So HR and IT and business
    improvement, finance
  585. they all see what the changes are
  586. that are going to be in the next month,
  587. and they say "Yeah,
    that's actually the right way to go."
  588. It means you can also prioritize that list
  589. and include that in your own Agile sprints
  590. but you've got to have that in there
  591. because you just risk so much
    customer confusion
  592. if you change things
    in ways they're not expecting.
  593. Also make sure you've got
    a pathway to do continuous improvement.
  594. Part of the reason
    we got stuck in an old system
  595. is that we didn't upgrade
    and we didn't think about improvements.
  596. So it just stayed there
    and there are things that you can do
  597. to sort of get these gradual improvements
  598. and keep it going in software.
  599. And also think about how
    you can upgrade in the future
  600. and what other
    automation things can we do.
  601. So certainly have a path
    that you can provide
  602. for continuous improvement.
  603. So where are we today?
    We're at 4,700 end users.
  604. Slightly more on the outside,
    so 4,700 paid employees
  605. who use it regularly
    every week on the inside
  606. and then we've got external
    customers on the outside.
  607. We didn't really think
    about it at the time,
  608. but what it's done is the cost
    for implementing Service Desk
  609. is not just fixing HR and IT's problem.
  610. You're also using that money
    to support your own customers.
  611. So think about which column that changes
    from a budgetary point of view
  612. that it's not just the cost center
    that you're causing.
  613. 250 agents, people who work
    on calls every day of the week
  614. and it took us three weeks
    to get from the old system to the new.
  615. People talk about data migration.
    Just call it "legacy data"
  616. because one of the things
    that we did early on
  617. was decide not to migrate.
  618. So service requests and things
    within IT and HR
  619. actually have a relatively short lifespan.
  620. And we decided,
    "Do you really want to move
  621. all those old issues
    into your new system?"
  622. It's going to take you weeks
    and months to do it,
  623. and what's the real benefit from doing it?
  624. And HR said that they needed that
    because they wanted to go back
  625. to a call four years ago, so we said,
  626. "we'll provide you with an interface
    one day to do that,
  627. but we're not migrating".
  628. And when I spoke to other
    customers here last year,
  629. "data migration, don't do it.
    Stay well away from it."
  630. Since July we've done
    30,000 service requests.
  631. It's all ticking along quite nicely.
  632. HR went live on June 15 and IT on July 1
  633. and it's all been fine since then.
  634. And that's the performance
    degradation I talked about.
  635. For most people that was a couple of weeks
  636. they had to go through with pain,
  637. but considering the improvement
    of the customer experience
  638. and the agent experience they get now,
  639. that's fine, so we've dealt with that.
  640. But you start to get feedback
    and people saying,
  641. "How did you go?"
    and you get things like this.
  642. It was an absolute pain
    and a nightmare before.
  643. You fixed that, so you're
    much better to do business with.
  644. We have a base now,
    we can do this improvement,
  645. which we couldn't do
    before with the legacy system
  646. which is just impossible.
  647. So we are starting to see this come
    through from our customers.
  648. I guess what you're all after is,
    what are the costs?
  649. There's $105,000, so not a million bucks.
    It was 105.
  650. We haven't had to employ
    anybody else,
  651. and that's our yearly agent ongoing cost.
  652. Then from our office, the CIO in the UK,
    that's what they say.
  653. So thank you very much
    for coming to our session
  654. and I look forward to, at least
    one of you, giving a talk next year.
  655. (applause)