Enterprise Information Management

Though it may sound, I am writing this in 2007, I am fully aware of the dates. I just concluded a recent road-trip in the US meeting a dozen customers to understand the investment areas for next year. Despite the budget constraints due to the recent economic conditions, one thing is really hot - yes, MOSS. People are still wanting to use the technology in various ways. Days of experimentation though seem to be over. Now IT decision makers fully understand the product capabilities, its roadmap and have more or less concluded what they should use it for in their Information Management journey. I will discuss some of the key application areas for MOSS in this and subsequent posts.

One of the primary areas of investments is, of course, creation of a collaboration platform. Most organizations, who operate in "project mode" and have invested in MOSS, are almost certain that they want to roll this out as a standard. More importantly they have also realized the governance issues associated with this. Creation of sites for project collobaraion is a strictly controlled exercise. In addition a trend that I observed is that once the "projects" are over, an archival process helps in transferring the relevant artifacts to a more tradional document management system, where the Records Management processes kick in. Thus the conclusion was that the Records Center is still not an accepted technology.

Throughout last year, when I spoke to customers and analysts, I was hearing a common theme - people want to use MOSS, but are using it in very different and strange ways, which are dangerous. I am happy to say that by now, at least the customers I met are very confident about their MOSS journey and exactly know what they are doing.

Posted by Tushar Sachdev at 11:37 AM | Permalink | Comments (1) | TrackBacks (0)

By Rajiv Sabharwal, Chief Solutions Architect, Healthcare & Life Sciences

Every industry has its own unique perspective of a horizontal technology/platform, with its own nuances regarding the context and content of the outcome. Healthcare and Life Science is no different. If anything, information storage and delivery takes added significance in this highly regulated industry, simply because of protection provided to patient information thru multiple regulatory mandates.

Over the next month or so, I will make an attempt at discussing a few ILM (Information Lifecycle Management) imperatives in context of healthcare and lifesciences thru a series of blogs, specifically directed at individual implementation scenarios. I would sincerely appreciate feedback not only from horizontal perspective but also from industry and domain perspective.

Beside the obvious split between Healthcare and Life Science, the industry is further divided into minor sub categories, such as payers (primarily insurers), providers (hospitals, physicians, clinics etc) and PBM (Pharmacy Benefit Managers). On the life science side, the industry can be further broken down into pharma (drug manufacturers), medical device manufacturers, CRO (organizations that conduct clinical trials) and BioTech (organizations that will ultimately become pharmas provided their research turns successful).

Each of these categories are controlled thru different regulations and hence have drastically different information management requirements. For example the pharmas and biotechs are primarily controlled thru CFR 21 Part 11, a mandate that dictates many diverse issues including electronic signature, electronic record keeping, data management etc. The counterpart for CFR21Part11 on healthcare side is called HIPAA, which in turn controls data storage and delivery issues associated with clinical data.

The basic idea of this pre-amble was to impress upon the reader the complexity associated with data management (sorry, information management) in the industry. Afterall one is talking about data that could make the difference between life and death. There is no other industry (maybe with possible exception of food industry) where a small inconsistency in data stoareg and retrieval could lead to such catastrophes as is possible in HCLS. Imagine not retrieving a patient's allergy data and giving him/her pencillin by mistake. Worse yet, imagine not catching a particular toxin/side effect during clinical trial and mass-producing and circulating the drug. HCLS data management is serious business, literally and figuratively.

Today, I will delve a bit further in some specific HCLS scenarios to give you an idea about where ILM comes in handy before leaving the rest for future blogs, elaborating specific scenarios.

The ILM requirements for healthcare and lifesciences side of the industry are quite different especially from the perspective of business intelligence. Each of them attempt at synchronizing data from large number of underlying sources but in healthcare, the data sources are usually quite structured and are usually intra-organization whereas for life sciences, the underlying data sources are highly diversified and include quite a large portion of external public-domain information sources.

The healthcare organizations (at least on payer side) have largely grown inorganically, a heck of a lot of acquisitions. This has lead to situations where there are drastically different systems performing same basic task across multiple sub-organizations. It is also not easy at all to bring these organizations on a single platform as they each could indivdually cover huge number of members and usually have built very exclusive business rules specific to their business. For example an organization that serviced individual market may have drastically different claim adjudication rules compared to a payer who primarily services employer-based market. Once the orgs merge, it is not easy to merge the systems. The best the payers hope for (the holy grail) is an enterprise wide data access layer (EDL) that is smart enough to access disparate underlying sources and consolidate the retrieved data based on some predefined set of externalized rules. So basically, the EDL is working against a pre-defined data model (payer-specific attributes) and extracting data from disparate yet similar systems. Afterall, all claims adjudication systems require basic attributes such patient name, physician name, disease code, amount etc. On the provider side, the situation is very similar though there one works more against clinical data instead of financial data, as is the case for payers. I will discuss the interoperability, ETL, DW, and BI requirements for providers in detail in my next blog.

On the Life Sciences side, the situation is quite different. There the underlying data sources are not similar at all. Infact the sources may not be structured sources at all. How many of us know of scientists who mainbtain all their data on structured databases? Not many. Imagine some of the most crucial toxicity data for a compound being maintained by a research scientist in an excel spreadsheet (I am assuming even the theoritical scientists do not use tissue papers and napkins any more. Any bets?). Also the scientific community leverages a tremendous amount of research already performed and available in public domain. Obviously one would not want to redefine the double-helix definition of DNA. So now the data storage (more of data retrieval) problem becomes quite acute. We are not only talking about disparate systems, but we are talking about unstructured data, we are talking about public domain info (which is not bound to follow your organization's rules for data storage and retrieval. How I wish that every body had just listened to me, way back in 1995). So here the need is for more of a semantic integration, i.e., use some pre-defined finger-print to search the required data across inter and intra-organization domains, consolidate it against some pre-defined template and produce not '1 of 150Million' but preferably '1 of 20' result set.

I guess, this has gotten too long. Well I will shut up now (how does one do that when one is writing). Next time around I will go into details of using DW-ETL-BI techniques specific to an interoperability platform to setup a Health Information Exchange (the current rage in the provider market).

Posted by Guest at 12:00 AM | Permalink | Comments (0) | TrackBacks (0)

That is a million dollar question which encapsulates a judicious decision that has the potential to save you a million dollars. As a portal architect, executing portal projects for customers across geographies & verticals, I have come across instances where portal technology is sometime misused to deliver a simple transactional web site.

These days, the term ‘Portal’ has become fairly misleading thanks to the marketing, propaganda and hype surrounding portals. It often leads unsuspecting customers to believe that any kind of website should be implemented using the portal technology. In fact, I often see the term ‘portal’ and ‘portal technology’ being used interchangeably. Internet facing portals can be implemented without using the ‘portal technology’ by using regular web development technologies.

Not a lot of people want to deploy good old websites anymore. Most of the customers want a portal and would not settle for anything less than a portal. We portal architects have done our bit to add to the confusion by jumping to a foregone conclusion that all customers are looking at implementing the coolest and newest portals products when they talk about any new web systems.

So, does it really matter if a customer opts to select portal technology where a plain old website will do? Let’s look at a few implications of this case:

• Cost – Compared to the application server of the same vendor, a portal product costs considerably more. So, if you decide to deploy a portal server and only use 20% of its features, you are wasting a lot of extra money.
• Platform complexity - A Portal platform is far more complex than a typical web application platform. This can lead to longer implementation time and relatively higher maintenance costs.
• Performance - Portal servers bring along with them quite a lot of overhead which amounts to reduced performance and higher costs both in implementation and infrastructure when compared with a regular website.
• Team composition – For a portal roll out, you end up managing portal specialists as against web developers and specialists. Portal specialists are fewer in number and comparatively harder to find.
• Platform Flexibility - How flexible should your platform be? If you use a portal server, there are set of boundaries that are imposed on you by the portal framework. With a web application, you have much more flexibility to customize the application behavior.

As you can see, it does make sense to take a deeper look at this question, doesn't it? In my opinion, if the customers try to answer the following key questions, they can get a good enough idea about their portal needs:

1. Do you want to empower your users to be able to customize the website? This question can get quite tricky to answer. Please understand that by customization, what I mean is do you want your customers to decide what they want to see in different sections of your website? And will this vary per user (and not per group of users)?
   
2. Do you want to be closer to your consumers by personalizing the website based on their behavior and identity? This question is often misunderstood and usually ‘mis-implemented’. Personalization does not refer to the ability of a user to change the color scheme and the look and feel of your website. It’s more about targeting and customizing the information a customer sees.
   
3. Do you want your partners/third parties to be able to use some of your components from your website as gadgets or services to create mash-ups?
    
4. Will teams from different departments of your organization contribute to building the website, working fairly independent of each others?
    
5. Do you have multiple existing applications that you are trying to integrate and present a unified experience to all your customers?
    
6. Are you trying to establish a space where you, your teams or your consumers can collaborate to share knowledge or exchange ideas? 

If you have answered more than two questions with a ‘No’, chances are that you really do not need a portal solution. A plain web application can serve your purpose.

(Published on behalf of Chinku Simon, Senior Technical Architect, Enterprise Information Portals Practice.)

Posted by Amit Jnagal at 06:39 AM | Permalink | Comments (3) | TrackBacks (0)

Last week, I was at a “kick-off” meeting for a client that wanted to fundamentally refresh their online strategy. I was pleasantly surprised that they had already had some serious thoughts around governance once their new baby went online. It is amazing how many large sized implementations have got off the ground without this thinking being done up-front.

A portal’s content can be sourced from three channels:

a)      Internally produced content: Content that is produced by the organization – either internally or contracted out to a specialist organization

b)      Syndicated Content: Content that is produced by a trusted, specialist organization. The producer sells the content to multiple organizations. (e.g. news and images from AP)

c)       User Generated Content: Content that is generated by the portal’s customers and other site visitors.

Trouble brews when the governance processes fail to consider that these sources of content are fundamentally different and require different sets of governance processes. This is because the content from each source differs in:

a)      The copyright holder that owns the content / the licensing terms under which the content is used

b)      The quality, accuracy and fitness of purpose of the content

c)   The technical integrity of the content

Posted by Freddi Gyara at 10:53 AM | Permalink | Comments (2) | TrackBacks (0)

Many architects still believe that BI/DW and SOA are divergent Architectural paradigms and SOA is not applicable to BI. Some of the key reasons are

1.       BI requires detailed understanding of the data for adhoc analysis while SOA encapsulates data behind the service interface.

2.       BI requires high volume data being handled in batch mode while SOA serves a specific transaction which is well defined and data volume is low.

Now let’s put some thought around the following realities.

1.       BI solutions traditionally are being used by mostly tactical and strategic level users to analyze and monitor various aspects of business health and take off-line decisions. This creates a time lag between the information is viewed; decision is taken and put back to use in the business processes. Therefore, BI solutions are always a downstream system with one way traffic of flow of information.

2.       BI aims at creating a single version of truth of Organization’s information assets and used by business to run their not only for strategic and tactical business decisions but also operational decision making process which demands quick (in some cases instant) decisions.

3.       There are 2 distinct part of a BI solution, namely, Information acquisition and Information exploitation. In both cases, sources and destinations may be unknown. For example, Pharma companies need to buy sales data from external data service providers and also have to share data to outside providers for crunching due to regulatory reasons.

 

Scenarios such as above make it imperative to have BI solutions loosely coupled from the following standpoint.

1.       BI solution should be able to acquire information and consolidate it in a loosely coupled manner, meaning that it should be able to acquire data from multiple divergent sources and should be able to deliver similar divergent targets. Also, such processes should be event driven so that information is obtained in real time. ETL tools are moving in this direction whereby source and/or target can be a webservice.

2.       Similarly BI solution should be available as a service for the downstream Information consumer. For instance, a call center executive should be able distinguish between a profitable customer and an average customer when he/she receives a complaint so that appropriate prioritization can be done. Such situation is possible if BI can be exposed as a service rather than duplicating the same information at multiple places. BI reporting tools are moving in this direction.

Hence, I believe we will see increased affinity between SOA and BI architectural paradigm which are complementing each other making a closed loop between transactional and BI systems. Do you still see a conflict between BI and SOA?

Posted by Jayanta Adhikary at 07:47 PM | Permalink | Comments (1) | TrackBacks (0)

We all know by now that, EPM helps an Organization in efficiently using their business units, financial, human and material resources and thereby optimising business performance. It helps in bringing together all types of data / information, including both financial and operational information. Well, this data integration portion is contributed by BI. 

Businesses are run as per the metrics / performance metrics defined. Some of these metrics could be Qualitative and some Quantitative in nature. Qualitative ones capture the facets, which cannot be quantified, such as, Quality of Management, Efficiency of Employees and Confidence of Shareholders, and they are critical for the business continuity.  Quantitative measures mostly provide an objective performance measurement. 

I believe EPM covers important processes such as planning, forecasting, consolidation, where the foundation is laid through data integration from various sources, querying, analysis of the data. The underlying foundation is the handiwork of BI.

 

I think, EPM aims to optimize business processes while aligning them with organizational strategy. It is an approach that uses best practices, methodologies and information technology to manage the performance of an organization and guides the business to effectively use all its assets – people, processes and technology – to achieve the organization’s strategic goals.

EPM & BI integrates data from multiple systems in the organization, to provide accurate and on-demand reports. The framework helps in generating reports, for the managers responsible for decision making, through publishing insightful reports. 

A well aligned EPM function usually ensures continual success for the organization; they are continuously improving their effectiveness by:

1. Better alignment with other functions within the organization
2. Eliminating manual intervention in its processes, thereby reducing errors
3. Improving financial and management reporting
4. Better aligning goals with the results. Well defined KPI’s and measurement metrics
5. Effective planning and profitability management

I think, When an organization is implementing EPM, it improves its processes to gain edge over the competition.  It may be to improve revenues, to reduce cost, for better on-demand reports, for improved transparency or simply for better alignment of different departments and resources. EPM as a tool, offers all these advantages and many more, such as:

1. Cross-departmental alignment: Different departments in the companies are operating in their individual information silos, working only to improve their profitability and visibility. This is sometimes detrimental to the overall growth of the Company. EPM & BI tools increase the participation of all key departments, hence breaking these Silos and ensuring free flow of information

2. Single view of enterprise: Companies may have different systems, which were implemented at different times in the past. The most important challenge for an enterprise is align all these systems and present one single view of the entire organization. EPM & BIenables the company to present a single view for transparent reporting for all its stakeholders

3. Quick Response to Changes in the Market: Markets are very dynamic, so any tool which the company implements, needs to be very adaptive and quick to respond to the changing scenarios. EPM offers a platform for dynamic data update

4. Reduce costs without compromising profitability: As the competition increases, and the price-demand relation becomes very elastic, companies start looking for cost reduction in all spheres to maintain its bottom line. EPM by its tight control process helps in identifying the avenues to reduce costs and ensure optimal resource allocation

5. Better alignment of budgeting and Planning process with Strategies and KPI’s: More often the goals of the company and the strategies designed to achieve them are not well inter-linked with individuals’ KPIs, resulting in failure to achieve these results at enterprise levels and dissatisfaction at the employee levels.  EPM & BI helps in setting well defined KPI’s and aligns day-to-day operations with long-term goals of the enterprise

After defining what EPM & BI should be doing, there should be well defined Implementation Strategy also to achieve the same.

I believe, for a successful implementation of a EPM program, company needs to look at the following aspects, to take correct decisions and directions:

1. Strategize:  A Strategy map has to be crafted on how this program will bring in results and improve performance on a short, medium and long term perspectives, and align itself with the organization’s mission and vision
2. Understand the information needs: Needs to analyze the current information analysis standards, and the framework supporting the same.  Needs to define the gaps and statistical parameters of the data in meeting the to-be-analysis needs
3. Estimate: Need to define a Roadmap to achieve the final objective along with the associated effort and costs.  It is always necessary to understand the business benefits and associated cost savings to propel the program forward.  Benchmarking can help in accurately understanding the post implementation benefits by comparing the pre and post scenarios
4. Risk Provision: large programs are mostly fraught with risks.  So, it is very important to have a risk mitigation strategy also in place, by having a good understanding on all types of risks that can crop up
5. Implementation monitoring mechanism: EPM program should be properly monitored to ensure that objectives are being met.  Necessary resources and authority should be provided to the implementation body to make this happen.  The implementation body should be well positioned in the organizational structure to make this happen

Let us discuss some of the EPM tools that are available in the market.  I believe the following provides an exhaustive list of the same: Some of them being Balance Scorecard, strategy maps, Dashboards, Financial Consolidation and Planning, marketing performance management, Activity based management (ABM), Value chain analytics (VCA).  The ones which offer major benefits and help in more accurate forecasts and transparency are ABM and VCA.

Posted by Narasimha Rao Kopparapu at 10:55 PM | Permalink | Comments (0) | TrackBacks (0)