Here’s a quick breakdown of our billing practices. In most of our outsourcing contracts, the service billing is based driven by on “Resource Units” (RUs). A Resource Unit is any tangible or intangible entity which provides offers a measurement of workload or efforts required to deliver and support services.
Although a logical and apparently simple concept, it is but extremelyvery complex to deal with, especially when the parameters associated with an RU point to diversified data points that are often – spread across multiple data sources with ambiguous data ownership. Therefore, the billing process becomes very tedious, cumbersome and extremely intense labour-intensive oriented.
To make the matters worse, a configuration management database (CMDB) is treated as the primary data source for RU billing. People fail to understand that RU is fundamentally different than from a configuration item (CI). Historically typically, people tend to mix confuse assets and CIs and , are now they are adding RU in to this the mix-up.
People fail to understand that RU is fundamentally different from a configuration item (CI).
Typically, people tend to confuse assets and CIs, now they are adding RU to the mix.
DRYiCE Orchestration is announcing the availability of the an indigenously developed solution to build and maintain RUMDB to support the billing for our managed service contracts.
Asset vs CI vs RU, At a Glance
Asset |
CI |
RU
|
All asset information reside in Asset DB and is controlled by Asset Management Process. |
All CIsO reside in CMDB and are controlled by Configuration Management Processes. |
All RUs reside in RUMDB and feed to ARC/RRC and billing process |
An Aasset is any tangible or intangible entity in the IT environment which has an “economic value” and needs to be managed from a financial management perspective. |
Configuration iItem is any tangible or intangible entity used and required to deliver an IT service, and needs to be controlled from service management perspective. |
A rResource uUnit is any tangible or intangible entity which provides a measurement of workload or efforts, required to deliver and support services. |
The Asset Lifecycle is complex and while an Asset database is simple. |
CI lifecycle is simple but CMDB is a complex database. |
RU may or may not be governed by lifecycle processes, and. cCould be simple. |
Examples of Asset, CI and RU
Component |
Asset |
CI |
RU |
Remark |
Physical Server in Stock |
Yes |
No |
No |
|
Physical Server Deployed |
Yes |
Yes |
Yes |
|
Virtual Server |
No |
Yes |
Yes |
In a XaaS mModel, vVirtual server may not be a CI |
Service Desk Call |
No |
No |
Yes |
|
EUC Device |
Yes |
No |
Yes |
EUC device is not a service producing system –, it is a service consuming end node. |
Hypervisor Server |
Yes |
Yes |
No |
Host OS is usually not a RU but guest OS is typically RU. |
Batch Job |
No |
No |
Yes |
|
Incident/Request Ticket |
No |
No |
Yes |
|
Asset, CI, RU and MO connection
Examples of Data Attributes in Asset DB, CMDB and RUMDB
Data element |
Asset |
CI |
RU |
Remark
|
Serial Number |
Yes |
Yes |
Yes |
Unique identification number |
Relationship |
No |
Yes |
No |
How two CIs are related to each other |
Cost |
Yes |
No |
No |
Purchasing price of an asset |
Vendor |
Yes |
Yes |
No |
Supplier of the asset |
User Entity |
No |
No |
Yes |
The department in customer enterprise who is using this RU |
Billing Entity |
No |
No |
Yes |
The department that will pay for RU |
Billing Currency |
No |
No |
Yes |
The currency for billing |
ROAR Overview
ROAR is HCL’s solution for managed service billing. It has following 5 steps:
Step1: Data sourcing
For each RU, we define a primary and secondary source of data in order to collect information from multiple sources. A dedicated integration hub enables the seamless consolidation of data from multiple sources like CMDB, manual channels, directory services, discovery, event management & patching tools.
A dedicated integration hub allows seamless consolidation of multiple data sources.
Step 2: Data normalizsation
This refers to the Pprocess of replacing alternate representation of the same data entity in the record with a normalizsed value. With data normalization, Eeach attribute of a record can be separately standardisedstandardized against a preset value or preset format.
Step 3: Data Aaggregation
Data aggregation is the pProcess of taking data from multiple sources and aggregating them it. This phase of data sourcingusesing defined rules to create a clean and accurate data record database, one unique record at a time.
Step 4: Reconciliation
This talks aboutProcess of identifying the managed service billing components by pairing the resource component with the correct Resource Unit.
Step 5: ARC/RRC reporting and approval
Added RU Count (ARC) and Reduces Resource Count (RRC) is reported as the delta from previous month’s RUMDB and approval is obtained for managed service billing.
Billing is the final stage in managed service billing &Billing is done by finance’s SAP system.
Initially, upgrading service billing systems may seem like a daunting task. However, with a clear understanding of the different assets, databases, and data components out there, we can outline a clear (and simple) way forward.