A Dollar Today Is Worth More Than a Dollar Tomorrow

PDFPrintE-mail

Making an investment in your E-Business Suite today for a big pay-back tomorrow

Your friend must choose between two offers:
  1. You offer your friend $1,000 to be paid a year from now.
  2. You offer your friend a smaller amount today – maybe $900.

Your friend will choose the second offer: A dollar today is worth more than a dollar tomorrow.  The old adage rings true in IT organizations.

It is difficult to justify a project to streamline your EBS and make it align with business changes when money is tight.  An IT department is willing to spend more money over time maintaining current applications rather than making an investment today.  It is much easier to continue to spend money and effort reconciling systems with thousands of spreadsheets and custom reports because the money goes out in a slower stream and is less “visible”, doesn’t need approval from stakeholders, and the users have lived with the pain for so long that postponing a solution for a year or two later doesn’t really matter.  By investing a chunk up front to change their applications, companies can reduce long-term maintenance costs caused by having different EBS instances, thousands of operating units, and different charts of accounts, but companies choose not to spend the money now and to spend more over the course of a number of years.  One large cost today seems bigger than many smaller costs over time, but in reality, making an investment in streamlining systems ends up saving the business money in the long haul.

The cycle begins when implementing Oracle E-Business Suite.  To contain costs, and because a company didn’t understand how to utilize all the features of EBS, the original configuration was not scaled to accommodate growth.  Companies had already made the investment in Oracle’s E-Business Suite, only to find that with time, the business has changed and the implemented system hasn’t changed with it.  Instead, it is much more difficult to recognize a return on their ERP investment because multiple instances or operating units have been configured differently due to requirements that are different for parts of the business.  ERP doesn’t represent the “Enterprise” anymore, and the Total Cost of Ownership (TCO) is going up – money is spent on “running” the business, maintaining systems, and developing workarounds to meet changing regulatory and reporting requirements, rather than on innovation and on utilizing the system to get more revenue to the bottom line.  It is difficult to perceive the value in spending money on a project now rather than maintaining myriad configurations over a longer period of time.

Political attributes of management can also get in the way – consider when lines between budgets become blurred and spending buckets spill over into others.  It is common for companies to dip into other budgets and misuse funds not originally appropriated for maintaining current applications to do just that.  One company was spending 40 percent (about $2.5 million) of its application development budget to maintain interfaces between disparate systems, while it could have more aptly used the funds for their original purpose: removing – rather than promoting – silos and disparity.  In an E-Business Suite environment, such improvements include consolidating operating units, inventory organizations, or entire instances, or redesigning the current chart of accounts (moving to a single enterprise version) to minimize cross-validation rules, utilize logical ranges, and reduce data entry and spreadsheets.  Let’s return to the original offers and tweak them a bit:

  1. You offer your friend $1,000 to be paid a year from now, if he is willing to invest $100 today.
  2. You offer your friend $1,000 to be paid ten years from now if he is willing to pay $80 a year for the next ten years.
In this case, it is much easier to justify spending the money upfront and to go with the first option.  A dollar today is worth much more than a dollar tomorrow.  Unfortunately, the second scenario is much closer to the situation in IT than the original offers, but IT management fails to see it.  Projects to change existing applications invariably get pushed to the back burner.  The ongoing costs of maintaining current systems are so much higher than a comparative immediate investment to change systems that it is difficult to understand why so much capital is poured into maintenance.  It is wiser to develop an effective plan to change current applications and align them with future business requirements, as well as to use the money and effort saved in maintenance to respond to new opportunities and become more competitive in the long term.

Add comment


Security code
Refresh

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

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?

Show solution...

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."