Many CRM systems are specialized in supporting and catering to specific internal functions, such as marketing, sales, customer service, and even additional areas like digital commerce or field service resources. Defining and prioritizing the goals of the CRM application is essential. Is the focus on selecting the most suitable technical solution, the most effective business solution, or on enhancing the customer experience to gain a competitive edge? Frequently, these objectives do not align.
Executive Overview
- Why choose a Grants Management System (GMS) over reusing a Customer Relationship Management CRM) System
- Design mismatch – Concepts match in name only; in reality they are implemented and used for distinct purpose hence re-purposing CRM concepts to apply to GMS exhibit the failings mentioned in this document.
- High long-term costs – Costs of shoehorning a CRM become apparent and accumulate over time i.e. greater technical debt.
- High upfront costs – Even simple grants workflows require extensive and expensive development
- Can a GMS fit into a coherent Enterprise Architecture?
- Right tool for the job – You wouldn’t use a CRM instead of a FMIS. Similarly, if your business involves grants, a built-for-purpose system isn’t just sensible, it is necessary.
- Jack of all trades, master of none – Some CRMs e.g. SalesForce consider themselves the right tool for every job; there is considerable evidence that such claim is misleading and results in sub-optimal solution.
- The real concern is around data ownership / portability.
- A competent GMS (e.g. OmniStar Grants) has necessary integration points to make it fit into a coherent Enterprise Architecture.
- Is OmniStar Grants the right GMS for the job?
- OmniStar Grants is designed from the ground up on Grants concepts, having a lower TCO and inherent support for grants workflows throughout the grants lifecycle.
Scenario 1 – I already have a CRM
"I already have made considerable investment in a CRM. By reusing my CRM investment to support grants making, I simplify the architecture and keep enterprise applications costs down by re-using the same solution many times over."
Note: This is a common scenario and CRM vendors and centralised IT extensively use to justify extending the use of their platform to implement grants management solutions.
Answer: Some organisations believe they can simplify architecture and keep enterprise applications costs down by re-using the same solution many times over. While fundamentally this principle holds true, in the case of reusing a CRM architecture for implementing grant workflows is mixing incompatible architectures as each is designed to serve a different purpose.
Reuse of a CRM when incorrectly applied can have serious and costly consequences.
OmniStar Grants, a built-for-purpose platform, is specifically architected and designed to support large number of grants workflows in their entirety. In this case, the effort, hence cost, to support multiple variations or new grants workflows is minimal. This is because the fundamental constructs are repeatedly applied via configurations which is distinct from creating each one by bespoke development in a CRM. Furthermore, the UX and UI are already optimised to support a range of grants actors e.g. grants administrators, grants program managers and grants administrators, If using a CRM platform, a lot of functionality needs to be added to support grants workflows and even then, the experience or functionality is most likely to be sub-optimal or unacceptable. This is because a CRM is fundamentally designed for a different purpose.
CRMs are architected and designed to support customer relationship requirements. Extending a CRM to support the core principles of a grants management solution is a contradiction. You wouldn’t use a CRM or GMS as your Financial Management System.
It is possible that a CRM can be modified with effort to support a simplistic grants workflow. Even in such cases, the modification is a bespoke development and therefore the disadvantages of bespoke development apply. A major disadvantage of bespoke extension to a CRM is that forward compatibility needs to be maintained for it to continue operating when the CRM is upgraded. The bespoke extension maintenance is either performed by a third-party or the organisation itself. This usually has a high cost. This cost can become significant over time and may lead to organisations unwilling to accept upgrades as they fear it will break their system. It becomes a significant technical dept.
The CRM enhancements are usually driven by the CRM needs of the market/vendor and this often occurs without regard for the GMS extension that is implemented on the CRM. In such instances, the GMS function may require refactoring or redevelopment which is undesirable due to cost, risk and timing. It is known that some GMS functions are unable to be accommodated due to the CRM architecture and/or design restrictions. The grants functionality on the CRM platform creates technical debt further worsening the TCO for a grants solution on a CRM platform. A built-for-purpose GMS has workflows that are targeted to provide and enhance GMS functionality. For example, OmniStar Grants has in-built capabilities that are extensible by configuration changes enabling organisations to support numerous and varying grant programs. When a new version of a GMS is released it recognises and preserves the in-built workflows. In OmniStar’s case, the configuration’s forward compatibility is maintained contributing to considerably lower TCO for OmniStar when compared with CRM’s such as SalesForce and Dynamics CRM.
Note: The CRM vendor SalesForce promote their Rapid Application Delivery (implied Development) capability to develop grants solution on their CRM platform. Their term "Application Delivery/Development" still means bespoke development hence all elements of bespoke development apply, i.e. analysis, design, development, testing, support and maintenance. It also means for each grants workflow to be supported new development is required.
Scenario 2 – Can OmniStar Grants work alongside my CRM?
"I already have made considerable investment in a CRM. Can OmniStar Grants make use of my CRM investment to support grants making?"
Answer: There is considerable evidence that stakeholders strongly favour a solution that holistically works as they expect it to work. OmniStar Grants makes the stakeholders feel that the solution is built for them (even though is it configured for them). This resonance is a major factor in greater adoption of the system by stakeholders which is important in managing the change from their existing environment to the new one.
Scenario 3 – Enterprise architects are concerned with having a number of built-for-purpose systems in their organisation
"Should my enterprise architects be concerned about having a number of built-for-purpose SaaS systems in my organisation? Will these SaaS solutions fragment my organisation’s enterprise architecture and render it ineffective?"
Answer: The rise and spread of SaaS solutions is re-defining traditional enterprise architecture that are based on in-house developed systems or monolithic platforms or systems, such as mainframes or generic CRMs. Organisations have successfully and cost-effectively implemented a number of SaaS solutions that interoperate effectively. Such an environment recognises the specialist nature of each solution that organisations require to be efficient and effective. It is analogist to micro services where each solution performs its specific task very well allowing for scalability independent of each other and components to be replaced or upgraded easily as needs change. The enterprise architecture consideration is shifting to selecting SaaS solutions that have strong interoperability, forward compatibility and security capabilities such that the source of truth is maintained, functional effectiveness is enhanced and zero to minimal technical debt is created.
OmniStar Grants is a SaaS and has all the capabilities expected of a SaaS. The configurability of OmniStar Grants gives your organisation full control to implement grants workflows that are required. Changes made are forward compatible, removing the technical debt accrual.
Scenario 4 – Why should you choose a GMS over CRM for grants management
While you have a CRM, you do not have inherent Grants functionality. Grants added to a CRM require bespoke development. The question you need to ask:
- Is the lifetime cost of the bespoke development more expensive/risky than acquiring a built-for-purpose solution for Grants? (Note: In OmniStar Grants all the functionality is complete and pre-built).
- Do you have more than one grants process/program to implement?
- How much of the possible lifecycle Grants process are you implementing? For example,
- Are there milestones?
- Are there potentially any milestone risks to be mediated?
- Is this a multiphase application process?
- How are you going to communicate with the recipient over the grant’s lifecycle?
- how is the assessment made?
- Are we negotiating awards?
- There are multiple options which can be different over multiple different grants processes.
These will all require bespoke attention and development on a CRM platform. In relation to a CRM, any but the most trivial choices start increasing risk and the expense and the amount of bespoke work required to extend the CRM.
Ready to Optimise Your Grant Management?
