Rewind back to 2012. I joined a small company of some 100 employees as IT Director.The first observation was workflow, they used general IT tools such as Office to manage their workflow. There was repetition, duplication of information, silos.
There was definitely room for improvement.
Looking at the off-the-shelf solutions – they did everything! That was also the problem, they did too much. As construction companies are slow to adopt change by their very nature, having to move to a completely new all encompassing solution seemed daunting.
Also, during almost all demos we had we asked:
“We normally do this in excel, can it do that?”
Too many times the answer came back:
“No, but you can pretend this field will store it for you”.
At the end of the demo the list of custom development requirements was usually quite long.
One day I was showing a friend – Phil – some of these solutions and his response was
“These appear to have ‘evolutionised’, not revolutionised”.
He went on to say:
“Here, check this software out, you can build whatever you want, without coding”.
That software was Cherwell Service Management.
I liked the idea that we could build whatever we wanted. I hated the idea that we actually had to build it.
But wait, why can’t we build *only* what was needed? We could prioritise user/group needs (i.e. what’s in it for me?) which support the strategic objective of combining inter-departmental activities into a centralised system.
This way we could pay close attention to user requirements, address their needs, get their buy-in.. you get the idea.
Great, sounds like a plan. Where do we start? Fire up Cherwell and start with a blank canvas, that’s where. Oh boy.
And that’s exactly what we did. Field by field, form by form, requirement by requirement. We built, tested, and deployed. We then either moved on to the next requirement or improved the previous. Sometimes both.
Working this way, we- everyone – were forced to think about how we did things. If it made sense (in terms of the process chain) we built exactly that, if it didn’t we built something that did make sense. We were:
Focusing on value
Starting where we were
Progressing iteratively with feedback
Collaborating and promoting visibility
Keeping it simple and practical
Thinking and working holistically
Optimising and automating.
Without realising it we were adopting ITIL 4’s 7 guiding principles (it wasn’t even born then?).
I know this now because I’ve finally got around to getting my ITIL 4 foundation : -)
Yet there wasn’t a sniff of ITSM.
Instead of ITSM, we went on to build the Sales to order fulfilment system, comprising of:
Site Survey Management ->
Quotation Management ->
Booking Management ->
Contract Handling ->
Resource Planning ->
Invoice Management ->
Health &Safety ->
Inventory Control & Compliance ->
Training Resource Management ->
Skills & Certification Management ->
Staff Leave Management ->
We even built a system that managed employee Christmas gift allocations to customers. It took 4 hours to build and saved the usual weeks of Xmas frustration, let alone replacing dozens of copy of copy of the original spreadsheet.
All this, and STILL nothing for ITSM.
This story was so unique at the time, that I was invited to speak about it at the Cherwell Customer Conference at the Houses of Parliament in 2017. Ah, proud moment.
Since then I have moved on and followed-the-Cherwell-sun, participating in and developing many ITSM projects. After all ITSM is what Cherwell does and does well out-of-the-box.
Cherwell has also since extended outwards into the ESM space out-of-the-box with CSMe. I just happened to do it the other way around. Not that it matters, because whichever way you look at it, if you can think it – you can do it with Cherwell.
For low adopting technology industries such as construction, I can’t think of anything more fitting for the above reasons, especially when considering getting or changing an ITSM toolset.
Thank you for reading.