The Eternal Question of whether to buy or to build your software

Congratulations. You have a problem, a project, a budget and a deadline. Instead of throwing bodies at it, software is the solution but now you need to decide to build or to buy, that is the question. Or is it? I’m not so sure it’s a clear cut decision anymore. Build used to refer to hiring in house programmers to code whatever system was necessary and buy referred to the off the shelf products that could be purchased and run. This made sense when we were talking about accounting systems, Trading systems, CRM, Reporting, Lending, Collections, CLM, etc. We now live in the low code environment where building something does not require coding experience. It can be drag and drop. Couple that with buying off the shelf solutions that end up being so customized that you might as well have built it. So where does that leave us to make the decision of to build or to buy? Let’s look at what we actually need.

No modern system can rely on a single point of entry anymore. Client expectations dictate that various channels are necessary. In person, over the phone direct or call center, email, social media, SMS, web, mobile, tablet – both mobile enabled and native apps, all with the need to be interchangeable without losing content or context. A customer who starts in branch/store or in person but has to leave for an appointment wants to be able to pick up where they left off when they login later that day online. Or if they start online but get frustrated and call in for help, they don’t want to have to start the process from the beginning. This applies to internal stakeholders too. The information chain within an organization needs to be as flexible as the client facing options. 

So what next for our start anywhere data inputs? Well, there is a reason we need that data in the first place. Whether a new client wants to work with the organization, an existing client wants a new product or service, or even just everyday queries, complaints or information requests. All these should begin defined but flexible processes to complete the request as efficiently and easily as possible. The process is generally defined and usually staff are trained to follow a sequence of tasks to complete it with predetermined actions based on certain data inputs. 

Neither end customers nor system users should have to re-key information anywhere if it has already been captured somewhere. In fact, if information is available anywhere within the organization or from 3rd party sources like data providers, credit bureaus, screening providers, etc. it should be accessible throughout the process for all users who need it. The process is defined but the touchpoints should be interchangeable throughout and data gathered should be integrated where possible and structured where allowable. Drop down menus, lookup values, date fields and controlled free text values to ensure as much data quality capture upfront. This allows for much more automation throughout the process and less exception handling.

Now that data is in the process of being actively captured or updated, the artificial intelligence can be applied. Staff do not need to know all the details and even newer members can work on more complex cases because the system is using policy coded rules logic to automatically make decisions that staff previously had to have extensive training and experience to handle. No more mistakes while also allowing oversight and even quality control checks or outright exception queues for manual intervention if needed.

This all requires a systematic approach. The old idea of a manilla folder that sits in a staff members drawer for their client portfolio is outdated and creates an unnecessary risk. Clients being processed in isolation can be both limiting and redundant at the same time. If a corporate customer has directors that sit across multiple other clients, why would each individual review ignore the bigger picture. Are you also going to review the same director multiple times across every relationship or could you do it once and reuse that information across the organization?

They don’t even have to have common related parties for the benefit to be apparent. Similar industries, similar client customers, what if your client vendors/suppliers are also clients themselves? This brings us to how you need to process the information and why organizations need to look across the enterprise when considering software these days. If you view a problem in isolation and treat it as such, establishing budgets and issuing RFPs for each CRM, Fincrime, Client Outreach component, you will end up with spending more resources trying to integrate everything together than any potential saving that was initially hoped for. Now apply that for every region or line of business that might get separate budgets and oversight and you will end up with 8 versions of the same software that needs to be integrated with itself due to heavy customization per area eliminating any economies of scale they could achieve.

A folder in a drawer that needs to be reviewed annually or otherwise, with staff needing to be trained what to do and when to do it. The entire review (or new onboarding/additional product/service/etc) can be broken down into composite parts that may or may not be handled by other people/teams. The system can then determine when a task is complete or when enough data is captured to be sent to the next person for their input. All these are structured as cases and sub-cases within. This way each element of the case can have its own deadline, escalation path, assignee and approvers. Instead of one large task that a staff member needs to be experienced enough to know how to complete and who to go to for various elements within, the system now assigns the work and ensures its timely completion across the entire company with as many tasks automated as possible to free up the decision makers to focus on what is important.

This is all well and good from a business standpoint. The work is known and what needs to be done. But when we are trying to decide if we should buy or build the software ourselves, how does that factor into things? Well let’s assume there are multiple sources of data across multiple systems. Any modern system is expected to be API driven and have low code/no code capabilities. A reasonable assumption for faster and flexible software. Everything these days needs to be treated as a microservice of sorts to avoid the old style software monoliths. Software should be installed and used because it is the best available and future proofed to adapt to change as needed. Too many offerings are entrenched and only maintained because they are too difficult and time consuming to replace. Most of this is because rules are hard coded, probably entwined with the data itself, data is not only integrated but replicated multiple times for each separate piece of software in the information chain and if you try to replace one piece, the entire system could break. Too much of the old thought process, if it isn’t broken then don’t fix it. What is really needed is for all those component pieces to be microservices, taking data that is needed, applying automated rules or user inputs/reviews and passing it along to the next microservice. Data should not be stored in more than one location. It may be federated but not replicated outside of backups. Your CRM, Onboarding, KYC, Client Outreach, etc systems should only access the data they need and not be data repositories themselves unless you have picked one to be. Replicating the same data across multiple locations and the rules that govern it is an exercise in futility as every extra system added will multiply the complexities involved.

This brings us to the final consideration. Whether you have a single source of truth/Golden Copy or multiple redundant and competing records and systems that can update them, you will still find yourself in another layer of requirements based on line of business, jurisdiction, client types and products/services. An individual is treated different to a company or trust and differs by consumer/retail, commercial or corporate lines of business for requirements and suitability. At the most basic of examples if we have 10 types of clients (individual – single, married, etc, private company, public company, trust, charity, etc) and you may operate in 10 regions, and you might offer 10 types of products/services, we are already at potentially 1000+ rules that could be applied. Wouldn’t it be so much easier to define rules for a region, for a line of business, for a client type and products or services and let the system resolve the requirements instead? Removing duplicates and reusing data points that were previously provided. This is the benefit of abstracting your process and rules from your data layer. 

So now when we consider the old question of buying or building software, we know we need omni-channel orchestration, process automation where possible, flexible rules logic, case management for oversight and auditability, low code and API driven, an abstract data layer and an intelligent rules engine that can inherit from different logic layers. The tech market is full of innovators who gladly satisfy every niche problem that can be thought of but at what point does it stop making sense to have ‘off the shelf’ products that all need to be coustomized and integrated with each other instead of building it yourself. Low code platforms can let you have 80% of your requirements available and you only need to configure that delta 20%. The best of both worlds is a low code platform that others have also built reusable components for so you can get the ‘off the shelf’ products as accelerators for your business while also having the ability for your staff or certified 3rd parties to build the rest of the requirements specific to your organization. To buy or to build? It really should be both.