Flipping The Fit Gap

I've been in the software business a long time now...I can remember from first-hand experience how things were done 15 and 20 years ago.  It seems like one of the biggest changes from then to now comes in our approach to "Fit Gap".

Fit Gap sessions are part of most packaged application implementations approaches.  The idea is to compare user requirements with software functionality in order to see how well the software "fits" with those requirements and where the software fails to meet those requirements (each of the latter is a "gap").

In the past, the focus was on fulfilling identified gaps by manipulating the software:  personalizations, extensions, customizations...what ever was needed to support changing the software to fit end user business practices.  But times have changed.

Enterprise Application systems now come with industry best practices baked into the software.  In fact, when Enterprise Software vendors talk today about "transforming your enterprise", they're really focused on three things:

1.  Leveraging the best business practices baked into the software to improve a customer's business processes.

2. Providing valuable information about your enterprise from all that data collected by the enterprise applications system (transactional reports, business intelligence and analytics, etc.).

3. Improve your operational agility and provide an opportunity to redirect your IT focus by moving your IT operations to the cloud.

The changes in Enterprise Applications have changed the nature of the Fit Gap process.  The emphasis has changed.  The objective is no longer to simply move your business processes to a new technical platform.  Instead, the target is to determine how well the best practices baked into the applications will work for your enterprise.  In other words, will this software package make my business better?

Over the past few years, I've seen a change as Enterprise Applications customers have picked up on the change.  There's less of an effort on building big requirements up front.  Instead, those customers are running the software "plain vanilla" out of the box in a test run (or Conference Room Pilot 1 or CRP 1).  Afterwards, the Fit Gap is conducted...but with a focus on how well the current enterprise fits into the business processes baked into the software.  Changing the software mostly occurs when the customer enterprise is, for one critical business reason or another, unable to fit into a best practice.

Big change when you think about it.  Fit Gap has been flipped from an emphasis on "make the software fit us" to "how can the software help transform our business"?  Fit Gap has been flipped!