Do you consider application rationalization part of your annual cycle? 3

Information Technology and its applications have become a critical part of today’s business operation. In many companies, CIOs have seat at the table to help determine business and operation strategy to gain a competitive advantage. Equally, CFOs and CEOs are participating in IT decision-making process and are no longer just signatures on the paper. Even the consumer has become IT savvy with the advent of mobile devices and tablets that eliminated the fear if computer for all generation. My father uses his iPad to perform most of his banking tasks, his review of MRI /CT Scan reports and to manage his portfolio. This ‘IT consumerization” has now forced C-Levels to pay attention to how IT in integrated in the business.

You can also see that result in today’s world overall. The uptake of technology has become instantaneous (and many times, not by choice)–as a necessity. Hence the problem. In the race to keep up with technology changes and increasing customer demands for more access, companies are deploying technologies very rapidly. And within that process of doing so, their application portfolio is growing rapidly as well. I have visited many government and commercial companies in this last year alone and I have personally witnessed this as a common problem.

Let me try to put this in context of everyday life.

I don’t know how often you look in your closet–I did it first time in 10 years just the other day. I had shirts and pants in there that I hadn’t worn in those 10 years. I have never really thought about getting rid of those clothes, but now the situation is that there is no more space (although my wife’s clothes do contribute to the problem which, of course, is beside the point and so there is nothing you can do about that). The only option I had was to discard some clothes or buy new house with bigger closet!

Now you may think that buying new house for clothes is an absurd thought, but think about what is happening in companies today. With advent of cloud services (especially infrastructure as a service), it is now very easy to add infrastructure and storage (no it’s not like buying a new house, but it’s certainly akin to renting a storage unit just to store the overflow of a closet full of clothes).  Cloud services have allowed me to continually add new technologies and applications. And just like I reached the threshold in my personal clothes closet, a great number of companies are going to soon realize (if they haven’t already) that the IT bill is only going to go up–not down. So the cleaning out of “the closet” will soon be a must in most cases.

CIOs are now struggling to keep control over proliferation of data and security of data. It is an increasing number of controls from an SOX perspective. Does this sound familiar? So what is the solution? Conceptually, the solution is very a simple one–provided in the “closet example:” I went through my closet, made three piles of clothes. One pile was the clothes I wear all the time. The second was a pile of clothes that I wear some of the time depending on occasion, and the third was a pile of clothes that I did not wear. I kept the first and second pile. I made another run through the third pile and took out couple of items that had sentimental value and donated the rest. I have also promised myself that “cleaning out my clothes closet” would now be an annual exercise. Naturally it is very easy in this case (of the closet), but in the case of application, the same concept also needs to be applied.

Application Rationalization is a key component for organizations and for every CIO so that he/she can ensure the organization’s IT is performing its role to stay in synch with its competitive positioning in the business world.  There are also two things that make IT application rationalization very difficult.  Organization Change and Data Proliferation. However, it’s similar to being able to ride a bicycle. Initially it’s difficult to implement, but once you have the processes in place and governance structure in place it will become much more natural (notice I did not say it was easy!). In my opinion, this needs to be part of every organization’s annual budget cycle. This is an area where the other C-level managers need come together with the CIO to perform the analysis.

In the age of Cloud Computing and Modern Application, be aware that you may have application that is mission critical and is still running on older platform. Application modernization methods are the needs of the moment and it is important to take a very systematic and detailed, but (at the same time) very agile approach to portfolio rationalization. Application modernization methods also combine application modernization as well as new technology selection/incorporation as part of a balanced approach to application rationalization. Gartner’s Pace Layered Application Strategy provides a good explanation of this and is well worth the read. This is really a very simple concept to understand, and fairly easy to learn how to segment an application portfolio and go through rationalization process. It is how I decided to make three piles of clothes from my closet.

I suggest that you keep your organization clutter free. Keep the focus on your consolidation and modernization approach while embracing advances in technology. This can be made possible by taking control of ALL APPLICATIONS and DATA (modern and legacy) and making those items part of an annual cycle to rationalize and consolidate. If done correctly (the right methodology, governance and discipline), this annual or regular task will provide your organization with a focused ability to be able to keep up with ever-changing IT landscape (if not full, at least partial). More importantly, IT will become your tool for growth and not burden on the organization.

Requirements, Process or Solution driven methodology for ERP implementation: What works best? 1

This post was co-authored by Christopher (Chris) Sharbaugh 

There are countless papers and articles on top risks for ERP implementation success.  There are an equal number of articles about implementation methodologies to mitigate those risks.

These many thoughts can be distilled into three major ERP implementation methodology categories:

  1. Requirements Based – This is the traditional approach to software development. Collect an extensive set of requirements that the system should be able to meet and then try to map those requirements to an ERP software package.
  2. Process Based – This is a modified requirements based approach. It advocates defining end-to-end processes that satisfy capabilities the organization is trying to deploy using an ERP.
  3. Solution Driven – This approach assumes the vendor’s software has best practices implemented and advocates applying them to satisfy capability requirements; any deviation from that is challenged.

In order to really determine what approach is most suited for the organization, lets start with establishing common understanding of few common terms:

      1. Methodology is defined in the Merriam dictionary as a body of methods, rules, and postulates employed by a discipline. Any Enterprise Resource Planning (ERP) implementation involves multiple disciplines. The extent of each discipline’s importance varies across the industry and across companies; e.g. the extent of organizational change required during the implementation of ERP varies across organizations.
      2. However, there are some paradigms that work best for delivering solutions quickly; they address the needs of the organization, and provide the foundation for users to deliver return-on investment.

To employ those paradigms, there are some important characteristics of ERP packages that you must remember:

  1. An ERP is the vendor’s culmination and implementation of an extensive number of companies’ and industries’ requirements.
  2. Those implemented requirements are packaged as a series of business capabilities and processes that must be integrated into the using company’s end-to-end processes.
  3. And lastly, ERP packages reflect the vendor’s interpretation of the most effective way to perform each business process. These best practices eases compliance with requirements such as Sarbanes-Oxley. They can also help compliance with de facto industry standards such as Electronic Fund Transfer (EFT). This is because the procedure can be easily codified and adapted across multiple businesses that share the same requirements.

At this point you could say, “There you have it; process based implementation is the way to go.”

“Not so fast,” others may respond, “those processes need the company’s data, business rules and employee roles sometimes at the task and activity level documented as explicit requirements to support the configuration.” 

Additionally, the touch-points or interface to the company’s end-to-end processes must be documented and governance-approved so that they don’t create a burden with interfaces.  It’s also vital to face the fact that no ERP will be a perfect fit for the business; there will be gaps that have to be accepted or filled with manual processes, bolt-on solutions, custom code, or SOA components.   The gaps must be defined at the requirements level to properly understand the business impact of filling them or not.

Now you’re thinking, “OK, now they are leading me to the solution driven approach.”

A solution driven approach is when the ERP team uses the actual software with the targeted users as an analysis and design tool.  It is a very powerful approach, especially when you consider users don’t have the time and organizations don’t have the money to perform extensive process modeling or requirements definition.   Additionally, when organizations invest in a process or requirements approach without referencing the ERP solution, more often than not they end-up with great and often expensive documentation of the as-is.  While this has merits, the impact is often more interfaces and extensions than less.  However, the solution driven approach will not support the first steps in the ERP journey: identifying the business problem; identifying ERP as the best solution; and selecting an ERP vendor that fits the company’s needs.

The bottom-line is that you need a hybrid methodology that is applied in the proper sequence to implement an ERP with higher velocity and at lower cost.  This fusion methodology is composed of:

  1. High-level Process Modeling
  2. Solution driven Process Decomposition
  3. Requirements driven Gap resolution

After the problem definition, you need to do some High-level process modeling in order to identify the ERP that is the best fit and select the appropriate vendor.   Process modeling includes scenario, capability, and architecture modeling.

  • Process models should not extend beyond the business and organizational flows with supporting data objects (e.g., invoice, customer, order, receipt, service request) and supporting systems.
  • Business scenarios are initial and high-level use cases.  Remember, the ERP has all the basics covered.  The scenarios should focus on the critical sub-processes or activities that make the company truly unique and are “make or break” for selecting using an ERP product (e.g., remote or mobile transactions, contracts, sales and inventory planning, pricing, invoicing, collections etc.).
  • The capability modeling should identify the must and should have features needed to support the processes and scenarios (e.g., RFID compatibility, Compliance, Multi-language, Automated approvals, Contracts templates, Serialization, Part numbering, # of users, locations, etc.).
  • The architecture model should identify the applications (purchasing, financial, inventory) that will be impacted or replaced by the solution and the enterprise solutions (e.g., security/identity, portal, messaging, ETL, Business Intelligence, encryption, etc.) that must be integrated with the ERP.

If you find the modeling team is at the activity, swim-lane, database table, or protocol level; stop: you have gone too far.    Additionally, the modeling will support investment prioritization, dependency identification, and team alignment for Agile development.

Once you have picked the vendor and modules, the solution driven approach will help bind the remaining processes and architecture decomposition to the ERP capabilities. It will also provide users with something they can see and touch while they define the detailed data, business rule, and role requirements at a level that can be configured by a technician.  Additionally, the team will be able to identify real process and capability gaps and their impacts to inform decisions about building Reports, Interfaces, Conversion, Extensions, Workflows, and Forms.

These gaps are where you can apply the traditional requirements driven or Agile approach; the team is essentially embarking on a custom development effort within the ERP project.  The identified gaps must be carefully evaluated and should be discouraged vigorously.  There are many tasks that will be more efficient with an ERP application and there will be some tasks that will be less efficient.  Keep in mind that any custom development in the ERP environment increases the possibility of a failed implementation. By some studies, 71% of total ERP failures are the result of extensive customizations and/or extensions under the guise of gap resolution.  You must document the requirements well and make sure that they are must have to successful business processes vs. just matching the way your organization/business is accustomed to doing or likes to do things.

An ERP is still the best alternative for replacing legacy applications and standardizing processes across the enterprise. It is important to apply a balanced approach and the right mix of methodology to be successful.