Skip to Content

Making tough choices about software solutions

RISKY PROPOSITIONSThere can often be a lot of technology buzz that one has to cope with and CIOs probably have to deal with more than their fair share of what’s new and cool and relevant.

It is curious that the higher one is up the totem pole, the more business relies on your opinion but the less technical and even functionally competent one tends to be. It is a relatively unrealistic expectation to have the CIO know and understand all the nuances and gotchas associated with a specific technical solution that is purchased for enterprise deployment. After-all the CIO is there to paint the vision, surround him or herself with technical experts and essentially hire well and appropriately. 

This is of course in the “ideal world”. 

In reality, we see CIO’s, IT Managers and business analysts with a wide range of technical and functional competencies. Some have been in the business for many years and were once operations aligned and are now technology solutions aligned. Some have only ever worked in the role or group that they are now, and some of them may even be so tenured that they will retire in those same roles or groups.

Some, bless their souls, only know ABAP and the world of SAP and look with concern and derision at some of the product brochures that cross their desks as enterprise class solutions. Then there is what I consider the “software bees”. Like apian explorers they are constantly looking for new and interesting challenges and new and interesting technologies can be the nectar that they seek to keep them energized.

Competent but without vision

The problem with this last group is that if they are not steadfastly committed to a given organization, they run the risk of heavily influencing those around them to buy into solutions that ultimately may not be a good fit for the culture of the organization or the requirements for solving the problem. These solutions may even tear up the stability of those who care and feed enterprise class systems like SAP.

In addition, if they have a track record of alighting and settling on new organizations frequently, they rarely see solutions into maturity and ultimately never learn about true appropriateness to solving the business problem at hand. Consultants can also be candidates for this group because often they are engaged to consider and resolve specific business problems and when their job is supposedly done, they move onto the next project or assignment.

Update_SAP_ERP6_EHP5 smaller.jpgThe thing about software solutions though, is that to be a true solution as opposed to  bandaid or quick-fix software –  their use can go in a variety of different directions. Give consideration to the use of LSMW as a tool for loading sales orders with VA01 , material master data with MM01 or something similar.  LSMW as its title suggests, was developed as a tool for use on SAP systems to migrate legacy data to SAP systems. In this context a legacy system could be almost anything. It could be a PLM system, a competing ERP product or data from another SAP system. The idea here was to be able to move large amounts of data into SAP systems from other sources. The tool was conceived as a way to fast track the loading of the relevant data. All too often though, LSMW is used as a generic wrench, screwdriver and hammer for loading all manner of data objects.

As a result of a relative low level of effort required to learn how to use LSMW, it is often one of the first things that IT organizations use to load or change data en-masse but is it the most appropriate solution for the business? There are many LSMW solutions in the field but there are as many abandoned ones and probably just as many that are constantly being complained about. LSMW in some respects is the perpetual band aid and one that should be used with a high degree of caution.

The days of IT being the data stewards of the organizational data have almost completely gone. There are a few smaller organizations where this is still the case but for the most part business owns the data. Business is responsible for its quality, keeping it current and ensuring accuracy. IT remains responsible for the inherent underlying technologies and for sustainment of systems but the data itself is usually not IT’s responsibility. Given this last fact, including the business in IT decision making about the kinds of software tools to be used for data governance is critical. Conversely, it is incumbent on the business to make sure that IT is a participant in the selection of IT tools that the business feels are most appropriate for managing their data. Neither party should be excluded from the consideration of tools nor products especially if there is a perception that ultimately both parties will need to come together to resolve problems as they arise. 

IT cannot help the business if it doesn’t understand what the tools do or how they work.  Business can’t constantly revert to IT to triage incoherent system messages that arise from using IT-centric tools to automate standard business processes.

/wp-content/uploads/2012/02/bee_swarm_303051.jpgSoftware Bees

Returning to the issue of software selection by “software bees”, this is an area where business needs to be really careful. I have previously written about how business and IT should be cautious about using forms for everything that they want to simplify – forms are cool and can be nicely controlled but they don’t lend themselves to all scenarios and you have to be careful about picking a form to do something that you really need a software application for – business bees will often suggest a form to solve a complex business scenario that is prone to bad data entry – sometimes the real solution is more training of users or better SAP configuration and controls.

Software bees will tend to go after what is fashionable and trendy and in particular, things that they haven’t played with before, typically they will not recommend LSMW but if that’s all they know, don’t be surprised if they suggest it! Likely erring on the side of wanting to be frugal,  IT and business should be careful about considering ‘free’ tools like LSMW for mass creates and changes versus 3rd party products that seem similar but often have differentiating factors especially in the realm of error detection, reporting and pre validation.

Free technology always has a price – often it’s usability or functionality

In a similar vein, if you know that you are going to receive a lot of orders from a particular source in a particular way periodically, why wouldn’t you invest in an EDI solution or develop a proper ABAP or JAVA solution like an interface that can be scheduled, monitored and managed? There’s a strong case for ad-hoc creation of mass upload or change scenarios based on the flow-logic of SAP transactions like that leveraged by BDC sessions and LSMW as a well as 3rd party products but there is also that grey area with a multitude of shades or hues that justify something like an LSMW script but don’t justify a permanent technology solution like a fully developed software interface. If it is a straightforward process that happens for modest amounts of data on a semi regular basis then batch data entry methods may be the way to go.

Consider that “today’s fashion can be tomorrow’s pain”, I recently looked at a number of “legacy” solutions that were implemented by companies to solve specific business issues and which have either failed to meet the expectations of the business or which have declined in usefulness due to changes in the way the business is run. Many of these solutions were built with LSMW components shoe horned into the final solution but some also applied 3rd party technologies that were possibly very innovative in their time but relatively unproven or immature. Some even deployed the SAP software development flavour of the day, like a BSP or Adobe Form.

A classic case in point, is a catalog load utility that used Java to load data files via a portal browser session and another that parsed a word document into a PDF that could be attached to an SAP record. When these solutions were built they likely met with IT and business approval because the business liked the technology and IT felt they could develop it but ultimately when it failed to work consistently and the ability to determine the point of failure and recover the processing, it proved too difficult to work with.

Consider your technology choices well despite the buzz of the software bees with these key criteria.

  • Talk to peers in the industry about how they solved their problem
  • Get consultant and vendors alike to provide contactable references.
  • Understand the solution support model (in-house, 3rd party etc)
  • Get the history of the consultant/vendor/technology
  • Search for and float questions on expert networks like SDN.
  • Perform due diligence on the technology stack
  • Be clear on whether this is planned as a bandaid or a long term solution and what the ROI needs to be

Make sure that if you are blazing a trail with some new and shiny technology, that it will be something sustainable and will provide you with either a rapid ROI or many years of viability as a business solution.

You may not have an accurate crystal ball but you don’t want to spend the rest of your career gingerly navigating mine fields of failed technologies.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.