Business Information Suffers from the Balkanization of Enterprise Software

Enterprises can be broadly divided into two categories –

• Transaction oriented businesses that have a high level of automation in the production or delivery of their goods and services – such as manufacturing, consumer services and trading
• Knowledge oriented business where people are embedded in the decisions that need to be made in order to create the output of their businesses and where the decisions rely on human judgment utilizing less than perfect knowledge or data – Pharma R&D, E&P, finance and investment banking, and invention of high technology.

Consider the diagram below that compare two types of enterprises. Transaction heavy industries tend to have their core businesses operate around a highly codified, data-centric network of sub-departmental activities. This is referred to as an ERP (Enterprise Resource Planning) system over the past two or more decades. People within and outside the organization (vendors, customers, contractors) feed information into the ERP through their contact points in the company; and other people are presented with the data from the ERP system for their planning and operations work. Ever since the existence of organized businesses historically these functions were taken care of by rows of clerical staff who managed their inbox and outbox folders full of memos that flowed across the company to execute the business and fill ledgers which recorded these transactions. ERP systems did away with the manual grunt work and replaced those early cow-paths with a digital network of data highways moving transactions along into electronic ledgers and data bases.

The typical knowledge intensive, decision centric enterprise shown on the right is still dependent heavily on the embedded human knowledge and experience for almost every aspect of their core business. Their interpretation, judgment, and decisions are critical in the execution of every context of their business. What these people do is clearly not clerical in nature and hence these are either difficult or impossible to replace with automation. Incidentally, it is not that transaction heavy businesses do not have their share of knowledge centric processes – they do, but it is mostly in the strategic layer of management. In industries such as E&P, Pharma R&D, investment banking and high-end technology or consulting services these are pervasive across as well as up and down the organization.

Transactions among the knowledge works are their interpretations and decisions which are documented in the memos and documents that they convey through mail or meetings.

From the 60s and the days of the IBM1401 data processors, attention has always been paid to the transaction oriented business processes and industries. Perhaps it was because it was easy, or because of the natural metaphor of data and accounting ledgers and the data bases (RDBMS) that came along in computer software.

The advent of ERP meant that:

• There was no need for explicit communications between people specifically to take an order forward or post information into the ledgers. If email existed then, they would have stopped using it for ERP managed business processes.
• There is no need to worry about search. Search was possible simply by searching through structured data bases. RDBMs have been very good at structured search from the very beginning.
• When compliance became de-rigor, it was easy to implement it because every point at which decisions are made on business information was well known and therefore it was possible to apply business rules to those points – or contexts.

Consider these historical steps that took place in the evolution of the ERP:

• Aspects of the business became data centric and information was transmitted on forms
• Ledgers or data storage for key business functions were created inventory, shop orders, sales orders, purchase orders, General Ledger, Accounts Payables, Vendor Lists, Accounts receivables, Customer Lists
• Data bases were designed to represent these ledgers (RDBMS) solutions for accounting, manufacturing, and order processing
• Software was developed to transfer reports and information from one order processing to accounting, OP to Manufacturing, and Manufacturing to Accounting.
• Finally all these were connected into one solution called ERP and out went the inter-office memos and mail carriers, and ERP became the business alter at which everyone came to seek their daily work.
• ERPs had run their course for about a decade before networked applications and data pervaded the enterprise and the balkanization of business information oriented applications began.
• Lastly, applications like email, digital document repositories, and collaboration software applications came in to automate and digitize the people to people connectivity needed in knowledge businesses (as shown on the right side of the figure). But these types of business are not core to transaction oriented businesses (imagine a Visa or MasterCard manager needing to collaborate with his counterparts to approve a new application the touch labor would be too high to make credit cards possible).

On the other side of the coin, an ERP type cow-path to highway conversion has not been happening in the knowledge industries. Therefore the natural outcome is for these silo single feature solutions to prevail and therefore these disparate applications have made it very difficult to have a homogeneous environment for relating and contextualizing information around business context the way ERP succeeded. A fundamentally different platform is required in order to streamline and flow information for knowledge businesses. This will be discussed further below.

Why is it difficult to search for information in a knowledge intensive business?

Almost a decade since search engines have captivated us, and changed forever how we look for almost any information, or anybody, or anything we wish to purchase true enterprise search is still as elusive like waiting for Godot.

Today, it is still not possible for a business person to search for:

• Content that is being co-authored by close team members
• Content that is not published to records or document management systems
• Emails that are being written by others that contain information that is useful to them and to which there are no restrictions to viewing them
• Meeting notes of other projects that contain information they are allowed to see Calendar objects that refer to events that relate to them and which they are allowed to see

In short, unless this disparate content are published and recorded into an archival system there is no easy way for people to find them. This is a severe limitation that has direct consequences on awareness, business agility and performance. Consider this real world incident in an oil company working on a major filed development program in Asia. One asset team that had a drilling ship under contract for four months with options to extend, completed their work a month early – keep in mind that these are very difficult to access and can take months to schedule. A few days after turning the ship back short of the contracted deadline, another asset team of the same company working a nearby field, found out that they could have had access to this ship if they had known; and that it would be a minimum of four to five months before they can expect to get another one under contract. This resulted in a significant cost increase not to mention a few months of delay to first oil and revenue. A simple contextual search would have unearthed the other team’s contract with drill ship owner, the emails that indicated the work was getting over, and the contact points in the company to contact and so on. This happens every day; the left hand knows not what the right hand doth.

Let us consider some of the underlying reasons why this is the case:

• Limitations of the Active Directory Roles (AD or LDAP)
• Dynamic nature of accessibility to any single piece of information over its lifecycle from authoring to usage in business to publication to archival into a repository
• Granular roles that people assume as they execute one or more project in a day of their business life.
• Dynamic assignments and changes in people assignments being done by business managers and professionals
• Churn of people in an organization

The balkanization of the business information space is along the lines of the applications. And this leads to the problems of disparate data stores and disconnects between data, information, communications, and people.

Consider an analogy that works to illustrate this. One building construction contractor (A) has a set of specialists – one is responsible for all the hammers. He keeps them clean and organized on hooks. Another keeps all the drills. Yet another keeps all the paint brushes – clean, organized on little hooks with nice borders painted around so nothing is misplaced. And, yet others keep the supplies. Carpenters know if they are working on the roof they need to pick up the roofing nails, hammers, tar, and tiles – before they begin their work.

Next door, another contractor (B) organizes all his tool and supplies according to what needs to be done. So the roofer goes straight to the roof, and finds that the roofing hammer, nails, tiles and tar are there – he goes to work right away. When he finishes his work, he simply dumps his waste, and based on what he did, new supplies are moved to the new section of the roof. A quick inspection of the hammer in case it needs any cleaning or work done and the site is ready for the next day. Which builder has more effective carpenters? Which one will tend to buy fewer tools? Enterprise software is organized by contractor (A) today. It is time to bring in Contractor (B) and let business people do real work.

Goto Top