Oracle BRM: Things to remember for Business teams, Designers and Architects (Draft)

The following topics will always be useful whether it is a greenfield implementation or an ongoing maintenance project. 

• Master Data Management
• Database cluster design across the enterprise applications
• Within Oracle BRM
• Cloud vs OnPrem 
• Account Management
• Pricing Management
• Services Management
• Inventory (Devices) Management
• AR (Payments, Adjustments, Disputes, Writeoffs) Management
• Integrations (OSS and BSS along with Tax and Payment gateways)
• Security (Encryption, PII, SSL, Authentication and Authorization)
• Billing Management
• Invoices and PDFs/Print Management
• Collections Management
• Usage and Rating Management
• DevOps and Code Management
• Reports and Documents
• Maintenance of the database/File systems of production
• Planning development, testing and integration environments
• 
  

1. Are we going to maintain the master copy somewhere in another application?

Master data management is crucial when there are plenty of applications which are going to store same data in a different format belongs to the business entities. 

Informatica's MDM allows to do that and IBM's MDM and SAP's MDG (Master Data Governance) are useful tools to maintain the master data. 

2. Are the business entity requirements fully defined?

The business entities in BRM are accounts, bill units, services, account receivables/payments, invoices, pricing etc.,

We need to build the requirements for the complete lifecycle of these entities. Let us take an example for one of these entities, which is 'account'. BRM allows to segregate customers by using customer segment. It is important to decide whether we need to divide the customers by a segment such as VIP customers, Government customers, Unlimited plan customers etc., The segmentation for accounts will also help in planning a multischema database if the implementation needs a multiple schemas to manage the millions of the customer information. It is important to divide the customer accounts equally as much as possible for each schema. 

It is important to think the requirements from the angle of leveraging the OOB functionalities provided by Oracle BRM rather than trying to fit all the requirements by customizing BRM heavily.

1. Do we need to have hierarchical groups?

2. Are there any sharing groups?

3. Should we have sponsored top-up group?

Note: In a B2B setup, if there are many services under one account then it is advised to create the service as a non-paying child under the main account. This is to avoid performance issues during bill runs.

BRM has 3 statuses for an account and those are nothing but 'active', 'inactive' and 'closed'. It is possible an active account can become inactive and inactive account can be moved to active status. It is also possible an active account can be moved to closed status. Once the account is closed, then we can't reactivate it. 

More about customer segments - Customer Segments

We need to question ourselves about the following.

• When can an account move into inactive status and what should happen when an account becomes inactive. Do we need to apply any charge when an active account becomes inactive. How long the inactive account be in that status? Are we going to close an inactive account automatically after certain days? Which customer segments can become inactive or closed. There will be plenty of questions around this area, so it is important for business stakeholders and architects to come up with the full and final requirements around the accounts and the lifecycle of an account including onboarding and offboarding. 

BRM supports maintaining the groups for accounts. One group can be hierarchical group, another can be sharing group and the third one is sponsored top-up group.

An account can be paying or non-paying account in a hierarchical group. A paying account can have either a paying child account or a non-paying child account. 

Refer to this document to related the groups for accounts - Account Groups

Watch this space for updates ... editing in progress