Building Intelligent and Performing Enterprises
Building Intelligent and Performing Enterprises
 
Login or Register  
 
Business Performance and Information Excellence Practice

Field Tips Listing Page
Business owned applications are a reality- Manage it
Business owned applications seem like an inevitable reality, where businesses are funding, developing and managing the applications on their own. This leads to data quality issues and chaos. Instead of fight or flight approach, a CIO can embrace this reality and manage it to minimize risk and disruption. Added benefit will be a reduction in these non IT-owned applications over time.
This Field Tips is linked to:  Data Quality, Core Data Management Tools,

Want to learn more on Data Quality?
Join Expert-Level Training Programs on Data Quality & Data Management

One of the key reasons for data quality issues is the mushrooming of small-time applications which are funded, developed and owned by business. (Please refer reasons for bad data quality). These applications come-up because of the following reasons:

  • IT cannot meet the delivery and demand expectations, as they have limited band-width and they want to focus (rightly so) on big things first.
  • IT cannot meet the cost expectations. IT has certain standards and Vendor management principles, which can make small applications too costly for business. Business feels that they are smart enough to do these small applications much cheaper and much faster.

CIOs have varying responses to these applications. One typical response is that CIOs disown these apps. This means that:

  • They will not provide production support these apps,
  • They will not include the data from these apps in their enterprise reporting system
  • They will not have data exchange between IT owned and business owned apps etc.

Some of these responses are valid from control and stability perspective.

BiPMinstitute.com recommends that that there is no wide blade single response to business owned application portfolio. We feel that the CIO should embrace the inevitability of non-IT owned applications. The CIO should work with business to ensure that they cause least risk and disruption to business.

The appropriate steps could be:

Create complete inventory of these applications and excel sheets:

This inventory should contain the following details:

    • The name of the application along with the brief purpose
    • The details on the business processes it support and data it provides in the reporting.
    • The owners and the team which supports it.
    • Brief history of changes
    • Technology platform of the application
    • Comments on the level of stability, risks and recent production issues.
    • The kind of data it contains (for example if it contains credit cards information or a customer's private information)

Classify the inventory. One line of classification could be:

    • Business-critical: The applications which if switched off for one day will cause significant disruption or exposure to business or reporting.
    • Business-important: The apps which if switched off, will not cause disruption as there can be a manual work-around. But the manual work-around is not sustainable.
    • Business- sensitive: The apps will not cause the business disruption, even if it is switched off for long, but it will add a significant manual load.
    • None of the above- These applications will not have a significant manual work-around and they are not part of core business processes.

Build a road-map for each of the application:

Create a road-map for each application, given its details and the classification. It makes sense to bring all the applications which have a strong linkage to core business processes into IT fold. One may not do that from day 1, but existence of a plan, can help us avoid risks. Following could be various options to a road-map:

    • Merge the applications with IT owned core system.
    • Implement the IT controls and procedures to the application, while it still being owned by business.
    • The application to be hosted in IT hosting infrastructure, while it still being owned by business.
    • IT takes over the application as is and merge it with IT core systems at a later date.
    • Shrink wrap the application and further enhancements to be done in IT systems etc...

Create a well-laid out policy for applications to be owned by business

The management team can agree on a well defined policy on how a business can own the applications. This can include:

  • Review by CIO before business goes ahead
  • IT laying down the architectural and controls guidelines, which business needs to follow
  • Given that IT might have invested into an ERP system, IT can lay down the list of functionalities which cannot be automated thru the business apps, and they have to be done through ERP.

This whole exercise will provide a great reference for the CEO and the management team on the extent of risk they are living with. Instead of IT to come-in once a business-owned application is in complete mess, this effort will allow you to be more pro-active. It is better to run a health-centre instead of an emergency unit.

DISCLAIMER- BiPMinstitute.com is not endorsing the principle of business owned applications. The whole premise is on how to best manage the situation. The fight or flight approach can be detrimental. The advise here will be that IT should not take the above as one mega initiative, as it will de-focus IT and business from business as usual. One can start with a function or with a set of business critical applications.


Quick Feedback- Was this information helpful ?
BiPM Support- Let us help you find what you are looking for-


Relevant Links to this page
Field Tips → Data Warehouse application is not limited to Analytics → Field Tips → Store as much detailed and granular data in data warehouse as possible → Field Tips → Data Normalization is not the best approach in Dimensional modeling → Field Tips → Keep the same names and definitions for all data elements → Field Tips → You cannot have a super-flexible Data warehouse → Field Tips → Dimensional models can be extensible and scalable → Field Tips → Data Marts should be ideally based upon a business process and not on a department. → Field Tips → Business Intelligence competency groups should be well-linked with business → Field Tips → Aggregation Queries on slowly changing Dimensions → Field Tips → Documenting your data-integration system → Field Tips → For a Data Warehouse/Data-Mart solution, analyze well, but be decisive → Field Tips → Maintain a trail of the key dimensional elements from source system to loaded → Field Tips → Conformed dimensions are must for cross-drilling → Field Tips → Checksum Approach for identifying the changed records from source systems → Field Tips → Data Quality is a subject of business ownership and not of IT-ownership → Field Tips → Don't create a hype on Data Quality Program. → Field Tips → Sponsor for a Data Quality Program → Field Tips → Business Case for Data Quality → Field Tips → Data Quality is not Perfect Quality → Field Tips → Engage the Vendors in Data Quality Program → Field Tips → How to get more data along with Sales leads → Field Tips → Ask for dates instead of number of years → Field Tips → How to Maximize the effectiveness of Data Stewardship → Field Tips → Field Tips Series#1- Data Mapping and Assessment → Field Tips → Data Management Standards for Data Entities will be a mix of collaboration and top-down → Field Tips → Data Management standards for data entities are not only for IT systems → Field Tips → Cascade your standards and guidelines to business partners and Vendors → Field Tips → Data quality assurance and control guidelines are no-brainer. Publish one immediately and evolve thereafter. → 
 
Back