Change as a Growth Enabler

PDFPrintE-mail

Despite the inevitability of change, the resistance to change is so pervasive that it has inspired numerous publications and an entire industry of change management experts dedicated to overcoming it (e.g., Lientz and Rea, 2004). The inability to change is certainly seen as a major flaw in business, resulting in the call for agile management, agile IT, and agile thinking. Yet, despite the dread with which many organizations face change, change can itself be used for strategic advantage—such as the changes resulting from the adoption of a disruptive technology, like the internet.

Many changes actually drive business growth, such as:

  • Mergers & Acquisitions
  • The addition of a major new customer
  • Disasters and other events that bring new market demands and opportunities
  • Expanding / global markets
  • Changing enterprise boundaries

Thriving through growth and change does take agility – which Gartner Research defines as “the ability to sense environmental change and respond efficiently and effectively to that change” (Newman and Logan, 2006). Agility can be seen at the root of other qualities demonstrated by successful businesses:

  • Innovation – the ability to think flexibly enough to perceive and respond to emerging opportunities
  • Sustainability – the ability to not only explore emerging opportunities but to reconfigure the business as needed to exploit them
  • Resilience – the ability to rebound quickly from a setback

Given the importance of agility in not only surviving but profiting from change, there are few good definitions of what makes an organization agile and fewer coherent plans for becoming agile. Gartner Research outlined such a plan in the 2006 Achieving Agility series, addressing issues within the corporation and across the value chain. In all cases, they recommended a formal information management program and sustainable data quality practices to achieve agility.

IT as an Agility Enabler

Business agility largely depends on agile, integrated information systems. “The information exchange required by agility is substantial. Because the first step in being agile is ‘sensing environmental change,’ information access and information quality are key enablers or inhibitors to agility” (McCoy and Plummer, 2006). The ability to exploit business-to-business (B2B) developments depends on the ability to extend trusted data to suppliers and customers, which in turn requires clean, consistent, semantic interpretation of master data (White and Koslowski, 2006). Quality information provides the foundation for growth. It is very difficult to grow and change if there isn’t a good, solid basis including a well designed IT infrastructure and good data practices.

For IT to enable growth and agility, it must be:

  • Accountable – with clear visibility into transaction histories everywhere in the organization it is needed – and compliant with Sarbanes-Oxley and other regulatory requirements
  • Flexible – easy to change in response to new processes, markets, and channels
  • Reliable – based on good data quality, trusted sources, and managed complexity

IT as an Agility Inhibitor

The hasty implementation of new technologies in the 1990s, without fully integrating systems or changing the business as needed to exploit the technology, often resulted in costly IT complexity and disappointment with the ability of IT to deliver promised benefits. As a result, few companies used the downturn as an opportunity to prepare for the return of growth by correcting the root causes of IT complexity (Mattern, Schönwälder and Stein, 2003). In The Adaptable Corporation, Eric Beinhocker (2005) cites “path dependence” on existing resources as one of the key obstacles to agility, because “A company...might be stuck with the wrong resources to go in a given direction because reconfiguring them would take too much time and money.” The conflicting constraints in large software systems such as Enterprise Resource Planning (ERP) packages can result in a level of complexity that makes change nearly impossible. Redundant applications, spaghetti networks, and information “silos” further increase the complexity and rigidity.

Designing IT for agility and growth remains a significant challenge, because information is growing exponentially, and even with the introduction of ERP and Service Oriented Architectures (SOAs), many of the problems that plagued disparate, legacy systems remain. For example, SOAs that create “modular” business processes by building a wrapper around existing systems have been touted as a silver bullet to the problem of IT complexity. But the old adage, “garbage in, garbage out,” applies here as well. The SOA itself will not deliver any more benefits than the legacy systems it supposedly replaces if it delivers the same poor quality data (Rettig, 2007).

 


 

Burke, B. 2005. Architecting the IT organization: The shoemaker’s children have no shoes. Gartner Research, G00128192, 20 June.

Craig, D., K. Kanakamedala and R. Tinaikar 2007. The next frontier in IT strategy. McKinsey Survey (spring).

Friedman, T., B. Gassman and D. Newman 2005. Predicts 2006: Emerging data management drivers and strategic imperatives. Gartner Research, G00136320, 22 November.

Lapkin, A. 2005. Management update: The seven fatal mistakes of enterprise architecture. Gartner Research, G00126623, 2 March.

Lientz, B. 2004. Politics and the resistance to change. In Breakthrough IT Change Management: How to Get Enduring Results, ed. B. Lientz and K. Rea. Amsterdam: Elsevier.

Loshin, D. 2007. Enterprise Knowledge Management: The Data Quality Approach. San Francisco: Morgan Kaufman.

Mark, D. and E. Monnoyer 2004. Next-generation CIOs. McKinsey on IT, July.

Mattern, F., S. Schönwälder and W. Stein 2003. Fighting complexity in IT. McKinsey Quarterly 1:57-65.

McCoy, D. W. and D. C.Plummer, 2006. Defining, ultivating, and measuring enterprise agility. Gartner Research, G00139734, 28 April.

Monnoyer, E. and P. Willmott 2005. What IT leaders do. McKinsey on IT 5 (fall).

Newman, D. and D. Logan 2006. Achieving agility: How enterprise information management overcomes information silos. Gartner Research, G00137817, 19 April.

Raskino, M., J. Lopez and K. McGee 2006. How CEO concerns at year-end 2005 should drive IT strategies. Gartner Research, G00136696, 9 January.

Rettig, C. 2007. The trouble with enterprise software. MIT Sloan Management Review 49 (1):21-27.

Tucci, L. 2007. Gartner to CIOs: Think, talk, and walk Like a CEO. SearchCIO.com. May, http:// searchcio.techtarget.com/

Vizard, M. 2007. Solving I.T.’s Biggest Challenge. Baseline, May, http://baselinemag.com/

White, A. and T. Koslowski 2006. Achieving agility: Enabling agility across a value chain with enterprise information management. Gartner Research, G00138350, 3 April.

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

May Puzzle

David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.

"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.

One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."

"That's right," said David.

Well how about Otcober 3rd?

"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.

"Oh, that's a Tuesday." David nodded in agreement.

Do we now have two rainmen? Or had Tommy figured something out?

Show solution...

Solution

Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.

So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.

Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!

So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.

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