Learning From How a Toyota Supplier Saved $1 million by Updating Its Tech Infrastructure

 

My second post in an on-going series of blogs on lessons we can learn from commercial sector technology implementations.

---

A recent article on TechRepublic shows how Toyota supplier, AW North Carolina (AWNC) spent $1.2m on new Cisco equipment, which has led to significant savings for them. Few charities will invest that amount in a new CRM system, but some of the approach which AWNC took provides us with very useful ideas for the benefits which charities may get from new CRM implementations, often regardless of size.


1) "Downtime at AWNC costs $272,000 an hour, so it's crucial to get systems up and running as quickly as possible. Any downtime, particularly in shipping, is incredibly detrimental."

Okay, so it's unlikely that a CRM system being down for an hour at a charity would have quite such high costs! However, downtime due to a poor or unsupported system or inadequate IT infrastructure is not always factored in to a charity's view on whether they need a new CRM/fundraising system.

So consider: what would it mean to your staff if they couldn't access their database for an hour? Probably, it wouldn't be terrible for most fundraisers/staff, they could cope for that time, although Supporter Services would no doubt find it awkward for managing in-coming phone calls. But what about half a day? Now staff will be getting more anxious, a backlog of income processing might build up, supporter services are finding it more difficult and major donor fundraisers can't see their contacts' details. What about a full day? Much harder now: thank you letters might be delayed, management for a forthcoming event becomes much harder, and what would happen if that day happened to be the day when you were due to do your Direct Debit claim?

So it's not just the cost of a new CRM system - all this needs to be considered when looking at investment.

2) "As a result of the new technology, AWNC avoided maintenance costs on the old equipment of $1 million in the first nine months the system was in place"

Again, unlikely for most charities that they will save $1m in nine months due to replacing a CRM/fundraising system, but I have come across several NFPs who are paying existing suppliers ridiculously high annual maintenance costs for what they are getting, even without upgrades and developments. And/or they have to have specialist, higher paid staff for their current, old system because there are so few people who can support it. So even if it is going to cost you £x to invest in a new CRM system, what are your savings going to be in the first 12 months? (In the next 5 years?) Forget "possible extra income" benefits for a moment, these figures are hard cost savings.

3) "About 40% of the savings will be ongoing and realized annually."

We forget this sometimes, that savings (and benefits of course) will not just be the first year, but over the following five to seven years. So in addition to point (2) above on immediate savings, what other costs will be lowered or made more efficient by a new system? Lower staff costs? Or maybe, the same staff costs but those staff being far more efficient, productive and proactive? Time-savings from quicker processes? Time-savings (and better productivity) from simpler, quicker development tools? Development you can do in-house now rather than having to always go to an expensive software supplier?

4) "It was very clear... that the infrastructure was not keeping current with where the world had gone."

We're all aware that digital is where fundraising is going. Yes, there will still be plenty of 'traditional' or offline income coming in for some years to come, but that appears to be declining, and GDPR/DP issues could be forcing our hand in terms of reducing direct marketing. There is a point when you do need to review how and whether your existing CRM/fundraising system can support you and provide additional benefits with your future fundraising plans because of changes in the outside world.

5) "It's common in a manufacturing plant to avoid buying new equipment in a misguided attempt to save money, with IT teams not realizing that the operational costs to troubleshoot problems and the associated downtime in a factory environment can result in even higher costs."

I love this! How many of you have suffered from this problem with your antiquated or unsupported fundraising databases?! (And it's kind of reassuring that commercial organisations have this problem too!)

6) "The big push for last year was solidifying the environment, and this year is all about pushing out into the applications and into the manufacturing space to impact yield inventory."

This is just a small point to show that any new CRM implementation does not have to be rolled out to everyone or to manage all potential benefits immediately. Plan for future expansions in the subsequent years after your immediate go-live - you don't need to, and shouldn't try to do everything on day one.

Example Risk Register Template

In my most recent blog, I discuss the need for a risk register. But if you haven't managed one before, then where should you begin? Below, you can download the template which I start with on all my projects. Plus a few words of advice and ideas:

• This is just an example! Just a sample template. I hope it is useful but don't just use it blindly. If it's right for you then great; but if you want to adapt it, simplify it, expand it then you should of course do so.
• Likelihood and Impact ratings: I'm a bit of a fan of not simply saying High, Medium, Low without trying to clarify what each means. Otherwise it can be very subjective and different people can interpret such words differently. Hence why I use a key to try to clarify each level. But...
• ... What this does mean is that I don't allocate 1,2,3 etc and thus this particular template doesn't have an 'overall risk' column where you multiply the Likelihood by the Impact; e.g. if you had a High Likelihood (and score it 3) and a High Impact (also scored 3) then multiply them together which gives you a simple 'risk factor' of 3x3 = 9. Some people like this sort of approach.
• The Response column: is very Prince, so if you want to adapt that then go ahead.
• Colours: I have added different sets of columns in the spreadsheet in different colours just to show a bit of structure. But once you get going you might want to make all columns the same colour and use a colour traffic light system for the individual rows.

And of course: there are many other ways of listing, recording and managing risks, and the risk register (and any template) is thus just one aspect of this. My way isn't necessarily best. There are many good ways of managing risks. And it won't make you a risk management guru overnight!

I hope this helps. If you have any questions or ideas/suggestions then please do add them in the Comments below.

---

Click on the image below to download the template

There is no such thing as a risk-free project - but that doesn't mean you should worry!

 

A few words only: I was recently contacted by a charity who had identified a number of risks with their up-coming CRM project procurement. And as a result, were panicking somewhat over what to do and how they could proceed considering everything they now knew about the risks involved.

In such instances, what is important to remember is this: there is no such thing as a risk-free project - never. Not even if you had pretty much unlimited time, money and people. Even then there will always be some risks.

But don't worry! This is not a problem. Don't panic if you identify risks - just manage them.

Identify risks, document them, understand them, understand their triggers and outcomes. Find out when they could happen in the project. Determine how likely they are to happen and what the level of impact could be. Then make a plan to mitigate them, assign someone to manage that plan and monitor it. Create a risk register and review it.

And if you haven't implemented a risk register before, then look out for my next post and I will publish the standard template which I use on all my projects.

Why CRM Systems Are Like Icebergs for Charities

 

There is no doubt that the adoption of the generic CRM systems like Salesforce and Dynamics is increasing amongst charities and NFPs. But in comparison to the commercial sector we are still learning about the use of them. And in comparison to traditional fundraising databases (Raiser's Edge, thankQ et al) we still know less about them. Consequently, although there are definite benefits which the CRM systems bring, there may still be issues which we don't yet know about.

Bring on the iceberg...

My iceberg theory…
The fundraising database packages have of course been around for many years. Many organisations have implemented them, many people have implemented them at multiple charities and of course the suppliers have huge experience of them. And they have a more defined scope.

So we know many of the potential risks and issues with such systems (as well as the benefits of course) and when we start an implementation we can attempt to plan for and mitigate such risks. And even though there will inevitably be new risks/issues which occur during an implementation, I could have a good guess at some of the areas that some of those might occur within.

Whereas the opposite is true for the CRM systems - at least in the specific and critical area of fundraising. Because although there are of course existing charities who have implemented Salesforce, Dynamics et al for their fundraising needs, in comparison to the fundraising packages the number is still low. And those that have done may well have used different approaches to each other and very different configurations of such systems.

This is partly because of their newness, but also because of their flexibility, options, configurability and the breadth of functionality in the base platform. You (we) don't learn that overnight. And even as you do learn the system, so we have to apply that to get the best out of them for sophisticated and sometimes significant fundraising requirements.

And it isn't simply a matter of therefore finding an experienced CRM system supplier because they will also only have limited exposure to implementing their system for fundraising at charities and NFPs.

Hence the iceberg…

Because if it is true that 90% of an iceberg is underwater and thus we can't see it as we approach it, then the same could be said of CRM system implementations. In fact, it could be worse. Because at least we know that we can only see 10% of an iceberg above water, whereas actually we have no idea really as to how much of the "CRM iceberg" is submerged below water, waiting for us to hit it as we plough through the sea of implementation. I hope that in practise that we do know more than just 10% of what the potential risks/issues are, but I can't say for certain right now.

Whereas, with fundraising packages, one can almost turn that on its head (an inverse iceberg?) and say that we probably do know 90% of the potential risks/issues which could occur in a typical implementation of such systems.

So what can we do to plan the safe passage of the good ship CRM?
The good news is that although we may not know exactly what is coming to potentially scrape our bows as we sail past, we can have a good stab at knowing the sort of areas in which any issues might impact and thus even if we can't put a final mitigation plan in place for such risks, we can start now to consider how we should plan for them.

What do I mean by that? Well, let's take a complex income processing scenario. Maybe we know that our ideal requirements can be met by CRM system X only through customisation and coding. In which case, we can watch carefully as we start down that route, plan to take it slowly, test as we go along, re-test as we add further functionality, actually go-live with limited functionality and then build on that, and always have a back-out plan which might mean, say, that if we do find it is getting too complex/costly, then at least for the implementation we will decide to simplify the system itself and substitute the ideal functionality with off-line or manual processes instead.

Similarly, if we find that record volumes are causing a problem which we didn't know about for data migration, then we may decide to initially just migrate more recent data and then transfer older data more slowly over a period after we go-live. Or for gift aid claims, we could even have a third-party package ready to do some initial claims if we do hit a nasty bit of ice. And so on.

And overall we can follow good practise for any CRM implementation: get our requirements straight, make sure it is all documented for client and supplier, manage scope-creep, don't let shiny new whizzy stuff take you off down a path which you don't need to go down (at least not on day one), insist on good project management (internally and with the supplier), never forget your operational needs, look for true benefits and so on. Keep it all as simple as possible.

Reeling it back from the simile…
I realise that I am wandering off down the iceberg simile a bit too much, so let's reel it back to finish this post. What I am really trying to say is that we must not forget that some of the fundraising implementations already done on these CRM systems are still pioneers in their own way. We can do as thorough procurement processes as possible, we can learn as much as possible from commercial organisations who are more experienced in their usage and their business partners/suppliers, and we can learn some things from other charities who have already started to use these systems, but because of their sheer size and capabilities we must keep our eyes open and be ready if we hit a problem that we just hadn't thought of. Be ready for this as much as you can, and if that does happen then hopefully it will just be a slight scrape on our midship and we can avoid replicating the Titanic…