Written by Chris Busbee Wednesday, February 20 2008
Being a piece of data is not as easy as it sounds. How would you like to be trapped in a vestibule only to be accompanied by the likes of endless tables and foreign keys? The lifecycle of a piece of data may sound as simple as CREATE, RETRIEVE, UPDATE, and DELETE, but I assure you that the frustrations that abound make life as a particle of information a bit more difficult than you might imagine. Put another way, I could be doing much more efficient work for my organization, but due to the way I am treated, I am unable to even come close to reaching my potential. But rudely, I have not even introduced myself.
My name is A. Little Datum, and I am a morsel of digital info that lives an arduous life as a fundamental unit of information that my company relies on to carry out its processes and uses to make important business decisions. We are a global computer manufacturing company with thousands of suppliers and millions of customers around the world. Although our profit and loss statements seem to please our directors and officers, I spend the majority of my time in silos struggling to break free in order to interact with the data in my company’s other information systems, all the while driving maintenance costs up and reducing data quality. Let me give you a quick example of a day in my life, but let’s start at the beginning when we were a small business with under 20 employees.
Back in the day, I would find myself existing as a piece of information that explained the supply cost our company would have to pay to purchase HARD DRIVE A to use in our finished computers. At a certain time, the hard drive manufacturer, our supplier, increased the price of HARD DRIVE A by $100, and therefore it cost us $100 more to buy each hard drive. However, our purchasing department failed to alert the billing department of the price increase, so we were still charging the same amount for each of our finished computers. As a result, our gross margin was cut by $100 per computer that we sold. In this scenario, I only existed in the minds of the purchasing department, and by their failing to communicate to the other organizational departments, I was confined to the silo defined by the purchasing department. In small companies, the silos can exist as simply communication failures between employees of the company, but the same problem exists (and compounds) for large companies with robust Enterprise Resource Planning (ERP) systems. Often, large companies have multiple instances of their ERP systems (possibly a server in each country or region, or for each line of business) rather than a single consolidated database and therefore often experience communication failures among each other due to poor integration of a number of systems that use the same type of data. These larger systems replace but carry out the same functionality as the minds of the employees in the small business, so reliable communication between them is essential to the elimination of silos.
My company exists today as one of the world’s largest computer manufacturers, and I am currently residing in our US inventory system as the product number (#435363) of one of the hard drives we purchase from one of our suppliers to use in the ITTY BITTY MODEL LAPTOP computer that we make. My sole function as a product number in our inventory system is to track the #435363 hard drives as they move through our manufacturing process (i.e. quantities on hand, quantities on order, bills of material, work in process, and quantity shipped). I have cousins in the other systems around the world who are used in our manufacturing operations, but I don’t know them very well – they have different numbers, different names, and different attributes. As an order comes in for the ITTY BITTY MODEL LAPTOP, I get selected and installed in the computer. Today, a very large order came in, and I needed the help of my cousins to fill it. OOPS, I just ran into the silo walls put in place because we have more than 10 different installations of our ERP software and there is no communication among them. I can’t find my cousins, and I don’t even know where to look – I don’t even know who is really related to me. This must have happened hundreds of times, and since our inventory instances could not communicate with each other (even though we use the same ERP software all over the world), we ended up with a plethora of orders that we were not able to fill. Needless to say, our customers were not happy, and we lost a large portion of our business.
I dream of the day when I am not trapped in this silo. I want to be part of the other systems so that my company can grow, and so our customers are happy. I want to get to know my cousins, and I want to know their history. Most of all, I long for a family reunion in a single, consolidated system.
| < Prev | Next > |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
Success Tips for Oracle Project Management
- Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
- Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
- If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
- Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
- Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
- Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
- Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
- Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
- Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
- Include governance, risk, and compliance management as part of the project plan.
- Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.
The Analyst Corner
John Van Decker, Research VP of Gartner, states:
"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."
