Own Your Digital Future: Build or Buy?

| Read time: 6 mins

Digital transformation is now a must-have for deathcare providers. Whether you run a cemetery or crematorium, whether a number of parishes are in your charge, whether you own a funeral home or combo, or even manage a large portfolio of deathcare facilities - you are now some way beyond the ‘if’ and well into the ‘when.’

Discover 7 benefits of digital transformation.

That being the case, the decision whether to 'build' or 'buy' a digital software solution is a hugely important one.

It’s important in terms of getting something that not only meets the needs of your operation in the here and now, but provides the scalability to look after you in ten, twenty or more years from now, and without large additional outlays.

If you have one take away from this article, let it be that.

With All of that being said, the right choice comes with pause for thought - being determined as it is by a number of factors that include time, money, and resources, as well as what your ultimate goals are.

So let’s make that decision easier by answering one simple question:

Why invest time, effort and money into solving a problem that’s already been solved?

Let’s break that down.

What’s the difference?

It’s important to first understand the difference between ‘build’ and ‘buy’ and what that will mean for you in practical terms.

To ‘Build’ is a solution where you design, build and maintain your software in-house. Whether this is done with an existing development team, hiring in a new team, or out-sourcing the work to a vendor or development company.

It’s not going out on a limb to suggest that there are few deathcare providers with their own inhouse software development teams, and fewer with additional budgets to acquire new ones.

In fact, cemeteries have told us overwhelmingly that the biggest challenge in terms of completing a build or buy project was perceived to be internal resources (85.7%).

To ‘Buy’ is to acquire a pre-built solution that can be configured to your needs.

In this scenario, you are not generally involved in the design or build - however you will play a role in developing the scope of the project and in the implementation process itself.

Here, all maintenance, security, updates and scalability is the responsibility of the vendor.

It’s also important to know that when considering build vs buy, that you’re not only looking to deliver exceptional value to your customers quickly and efficiently, but you are also setting your stall out for  the future.

Bear in mind that your most important asset - your data - will outlive your application, meaning it’s important to get it in the best possible place - both figuratively and literally - so that it can travel forwards through time.

The certainty of chance

We don’t live in a perfect world, and the journey to implementing a workable and reliable solution is inherently unpredictable - not just for the vendor, but for you.

This, in part, is because it can be hard to discern between what you want, what you need, and how to get either.

Getting there involves a number of challenges that simply can’t be envisaged at the outset. Many deathcare providers tell us that they know they need to do something, but they don’t know how or where to start.

And that starting point is: do I buy or do I build?

In this context, the most compelling reason you need to buy is this - 

If your needs can be met right now with a tried and tested vendor who can offer:

• A full product without gaps, with all functional and non-functional needs met;
  
  
• Quality support;
  
  
• Low risk;
  
  
• Predictable implementation;
  
  
• A clear return on investment
  
  

Then to either build something inferior yourself, or work with an untested vendor is, to put it mildly, shortsighted, and to put it less mildly, complete folly.

The point here, and the main selling point of someone like PlotBox, means you can benefit from a vendor who has long-term tenure, who has invested in their product with tried and tested workflows. 

For a tiny fraction of the cost of that investment, you can eliminate the build risk along with many of the challenges, as well as avoid the drain on resources versus starting from scratch.

Let’s talk about those workflows for a moment, because they’re an important factor.

Workflows

Workflows are the execution of process steps with data validation to replace manual process steps. 

Some things to remember about them are:

• They’re usually the biggest source of ROI on projects.
  
  
• The development of workflows can take 5 times the time of setting up the data sources they act on.
  
  
• Quality assurance increases exponentially with the number of processes you add.
  
  
• Workflows change, and you have to be able to respond to that - it can be very expensive to remain static and stick with the way you’ve always done things.
  
  

In short, successful workflow implementation equals improved ROI.

The next question then is do you have the resources to adequately define and execute on workflows?

If the answer is no, then a pre-built [buy] system is an absolute must.

But that’s only part of the story. After all, a solution is not a solution if nobody uses it...

User experience

The people who will ultimately end up using your new system play an important role in deciding whether your choice has been the right one.  Some food for thought:

• Users are reluctant to use a poorly designed system. An easy-to-use system generates user and feature adoption. How do you do that?
  
  
• Software best practices. Do you have the experience and knowledge to adopt those into your system? To ensure individuals aren’t going to stop when they come up against the first problem?
  
  
• Industry best practices and workflows. If your teams have the ability to understand them and the desire to adopt them - and we recommend they do - your best enabler is a system with these workflows already built in.
  
  
• User role configuration. Does your software have the ability to present users with only the information that they need?
  
  
• Documentation within the software and in user manuals. These are essential for staff to start using the system.

Failure to adopt equals no or negative ROI.

Will your staff use it? Can new staff get started easily?

If you are unsure of the answer, then ‘buy’ is your best choice.

Data Security

With increasing cyber threats, the security of your data is paramount. How will you then ensure that security is ongoing?

In opting to build something akin to a beta software solution or Minimum Viable Product (MVP) with an untested person or start-up - how can you avoid single points of failure, or worse, guarantee that they will always be available to you - leaving you and your systems vulnerable.

Also consider your legacy planning - an internal build, for example, can largely depend on one person or that one department - future proofing means not leaving yourself open to knowledge loss due to staff attrition.

Remember - vulnerabilities open you up to the prospect of unauthorized access to confidential information, the tampering with or destruction of irreplaceable data, interruption of important network functions, or even a complete shutdown of the network.

In short, to buy is putting yourself in the best position to avoid them.

And with that, it’s also important to note that not all cloud solutions are equal. Those protected by public cloud services, for example, can offer the highest levels of security. PlotBox, for instance, partners with Microsoft Azure (used by over 95% of the Fortune 500 companies), regularly backing up data which is stored securely across multiple data centres to protect against loss or corruption.

Learn about PlotBox cloud security.

Support

This is perhaps the most underestimated of all the requirements when looking at build projects. If going that route, you will need to be able to provide support for:

• Users who have general ongoing operation questions.
  
  
• Training for staff changes.
  
  
• Response to external change.
  
  
• Infrequently used features.
  
  

Diminishing, ineffective or inefficient usage equals diminishing or negative ROI.

Consider who will answer questions and resolve problems. Do you have the budget or resources to handle it?

If the answer is no, then ‘buy’ is a must.

The decision to build or buy.

The decision to build or buy of will of course be determined by a number of factors, and those may in part include what your minimum acceptable system is, what your minimum acceptable return on investment is, and what your goals or objectives are.

So again, consider the question: 

Why invest time, effort and money into solving a problem that’s already been solved?

If you’re still undecided, here a few points to think on:

• Is there already a solution available?
  
  
• Do you want year-over-year predictability of expenses?
  
  
• Are limited internal resources or expertise available?
  
  
• Will the complexity of the project exceed available resources?
  
  
• Do you want to adopt industry and software best practices?
  
  
• Do you need to realise a timely return on investment?
  
  
• Do you have concerns over usability or user adoption?
  
  
• Does the solution need to include workflows or business processes?
  
  
• Will maintenance resources would consume any return on investment?
  
  
• Do you want to eliminate the risk of a build?

Contact our team today to discuss your digital transformation options.