Archive

Archive for April, 2009

Driving IT Value in a Down Economy

April 29th, 2009

Oscar Wilde wrote, “The cynic knows the price of everything and the value of nothing.”  Unfortunately, current global economic conditions make it too easy to fall into this way of thinking.  Based on recent headlines, it seems that far too much attention is being placed on eliminating unnecessary jobs and far too little attention on actually cutting unnecessary work and increasing efficiency.  Contributing to this negative perception in the boardroom is the idea that IT projects are too costly, take too long to implement, fail to deliver differentiation, don’t line up with business strategies, and deliver value only when completed. 

 

Putting aside these negative perceptions, few people would argue the increases in productivity over the past decade are due mostly to advances in technology.  According the U.S. Bureau of Economic Analysis, businesses increased their investments in IT from about $3,500 per worker in 1994 to approximately $8,000 in 2005.  During this same period of time, annual productivity growth in U.S. companies roughly doubled after moving along at about 1.4% for the previous 20 years.  The challenge is ensuring that the dollars invested in technology provide the necessary return and deliver a strong competitive advantage.    

 

Align Business and IT Strategies

While aligning business and IT strategies may be a concept that is widely accepted, it is far less frequently accomplished.   The fundamental flaw that leads to this is that many IT professionals don’t focus on or truly understand the business need and business leaders do not invest the time required to appreciate the power and challenges of technology.  An example of this is implementing a customer relationship management (CRM) solution. 

 

I worked with a local company a few years ago who misunderstood that implementing CRM is more involved than simply installing new software.  They failed to realize that CRM is a business strategy and instead viewed it simply as a piece of software.  The value in their eyes was simply the cost of the software that they believed would improve their performance.  They never viewed it as anything more and therefore never got anything more out of it.  They are still wondering why it didn’t have the significant impact they were expecting. 

 

Successful companies effectively leverage software and other technology to enable their business strategies.  In my above example, failing at implementing a new CRM solution typically is a result of spending  significant amounts of time and money on implementing a piece of technology without the proper vision, strategy, and processes being defined upfront.  Companies, who adopt standard packaged software, unfortunately often end up adapting their business to the technology instead of adapting the technology to their business.  Although this can benefit companies who give up inefficient processes to utilize standard best practices, it more often leads to sacrificing competitively differentiating capabilities. 

 

Keep it Simple

Leonardo Da Vinci said it best, “Simplicity is the ultimate sophistication.”  This same idea applies to enterprise IT solutions.  Standards such as network protocols, platforms, databases, and operating systems should be limited to as few as possible.  IT projects typically start with just a few standards but most of the time they multiply due to additional requirements and initiatives.  Limiting standards and simplifying technology and design allows organizations to devote less time to quality assurance and more to building new functionality.

 

I recently visited with a large corporation that had 92 separate systems that held structured customer information; most of which were not integrated or connected.  This causes duplicate entry, more room for errors to occur, and the end result is a lot of inaccuracies on what is the most current information.  Imagine being a new employee at this company and trying to find something about a customer; where would you look?  Keeping things simple helps to deliver a quick and early win; one that builds confidence and delivers value to the business. 

 

Define and Focus on Priorities

There is always tension between who gets what they want and who doesn’t; just ask my daughter.  In the business world, this conflict is only intensified by prevailing economic uncertainty.  This battle between priorities can be between competing projects or conflicting goals/features within a project.  It is vital to the success of an IT project to define these priorities up front and to make sure that projects are not delayed or pushed over budget by non priority goals.  “Keep your eye on the ball” is a mantra that applies to many sports; it also applies to IT projects. 

 

Far too many times I have witnessed companies start a project with goals such as increased data integrity, increased scalability, and/or better access to data; but then get derailed by solely focusing on a non-priority item.  An example of this is a customized software solution we recently built for a company to replace an older application.  The previous solution was horribly inefficient and had significant data issues.  The new system solved all of their upfront goals, provided previously non-existent reporting, increased reliability, and the users absolutely loved it.  However, one person within this company almost derailed the entire project because one task required two additional mouse clicks compared to their old system.  Sometimes keeping your eye on the ball is harder than it seems. 

 

Technology is at the heart of competitive advantage and today more than ever that can make all the difference.  Technology can be a vital tool to help a company cut costs, better manage customers, increase efficiency, provide better business intelligence, and provide numerous other benefits.  However, the fact remains that technology in and of itself can’t deliver on these promises alone.  When technology is implemented as part of an overall solution with an equal focus on the business processes and the people involved it can be wildly successful.  The keys to success are simple; focus on making sure that IT investments are in line with business strategies, keep things simple, and stay focused on the end goals.   

Author: Eric Gjerdevig Categories: Technology Leadership Tags:

Context Sensitive Report Filtering Issue

April 29th, 2009

I ran into an issue about a week ago where I was completely unable to get custom context-filtered reports working in my CRM environment.  I created an extremely simple test report, since I figured the issue may be due to the complexities of the original report that I was having issues with, and could not get the report to work in my test environment or any other environment that I tried.  Microsoft Support has resolved the issue and here is what happened:

I had restored a backup of our production CRM database on a test server to use for an internal development project.  The original database was called Summit_Group_Software_MSCRM and I restored it as Summit_Group_Software_Test (notice the missing _MSCRM).  Aparently CRM detects a report as being a “CRM” report based on the _MSCRM suffix in the connection string, so without that, CRM thought my report was some random report not tied to a CRM datasource.  Therefore, CRM does not modify the report in any way, including the queries (which is how context sensitive filtering is enabled) or the connection string.  I had also noticed that the connection string was not getting updated however I was not too concerned about it since I was developing the report in the same environment that I trying to use it in.

There are a couple of resolutions to this problem:

  1. Take a backup of your database, restore it with _MSCRM at the end of the database name, and import your organization
  2. Before uploading the report into CRM, open the report in Notepad or another text/XML editor and modify the database name in the connection string to have _MSCRM at the end of it.

I opted for option one since it is just a development system with nothing else tied to the database and since it would get annoying to continually need to use option two while I design several other reports.  The implementation guide probably states that databases must be restored with a _MSCRM suffix but I did not bother checking.

The _MSCRM suffix was more import than I would have ever dreamed…

Author: Tyler Sand Categories: CRM Customization, CRM Reporting Tags: