Periodically I receive a postcard in the mail from a local community service based organization that collects unwanted household and personal articles. They clean them up and sels them in their local charity shop. Periodically I accumulate a small pile of things in anticipation of the postcard, and on the given day, if I remember, I put them out on the side of the road near my house with the postcard. This week they made their collection and one of the things that they refused to pick up was an old IKEA high chair. They kindly left a note to say that some things are not collected either for safety reasons or because they are too expensive for them to appropriately discard or recycle. Similarly they do not acceptcribs & cradles, car seats, carriages & strollers, baby gates, playpens, baby walkers etc. The position struck me as odd, to say the least. I looked online and the resistance to certain items seems to vary from state to state and country to country. With the increased emphasis on recycling and reuse and the push to encourage people to keep stuff out of city landfills it strikes me as interesting that supposed safety anxiety has superseded common sense with respect to something as mundane as accepting the donation of household articles, after-all I am not offering hypodermic needles, partial canisters of drugs or medical equipment. I am pretty sure that if I offered the high chair for free on a Yahoo group like freecycle or posted it in a free stuff ad on Craigslist it would be snapped up in no time at all. City dump and landfill pickers manage to survive in many parts of the world by recycling plastics, metals and certain chemical waste, books, furniture and appliances, even I have fallen into the category of a token dumpster diver, I have 4 very nice solid oak dining room chairs with wicker backs that were recovered from the dumpster area near my apartment complex some years ago. Though the upholstery is a little tired they function perfectly and actually are in better shape than some new ones that I bought around the same time. Some of us would never dream of foraging for stuff and castoffs in this way either due to anxiety or personal sense issues but I guess my third world upbringing prevails in pushing me to always consider repurposing what I already have, or what someone else would discard rather than add to the land-fill.
“The superior man seeks what is right; the inferior one, what is profitable.” – Confucius
It is interesting then, that in a conversation with a relatively new SAP customer this week that he and I engaged in a lengthy dialog around standards and standardized processes and his company’s interesting recycle project. In essence implementing standards or ‘deploying standard’ is often no more than applying best practice or preconfigured models to the way you run your business with an SAP system. Unfortunately, as this customer revealed, the standard doesn’t always hit the mark and sometimes it in fact jeopardizes the success of an operation or new implementation.
An article that appeared elsewhere on SDN by Vijay Vijayasankar speaks to some of the issues around Where should SAP draw the line for standardization and reuse? and I recommend this along with many of his other blogs likeIf the shoe does not fit, must we change the foot? as well as reading some articles by Oliver Kling on this topic here on SDN. We can hardly fault implementation partners and consultants for implementing standard solutions for customers over customizing the SAP solution or engaging in numerous cycles of add-on enhancements in the Z space but where is the balance? The choice of standard is a relatively safe one, one that is guaranteed to make the ‘system’ work as expected but not necessarily one that is a solution to the business needs.
Many businesses that have still not migrated to relatively standardized business process optimized solutions like SAP have resisted the migration because the gap-fit analysis suggests that the chasm is too great between the standard or industry solution offered, and perhaps how their home-grown or bespoke system meets the business need. On the one hand this is possibly true, the gap exists but the gap may not be one that cannot be closed. When you live and breathe a system solution daily and you have grown up in your business with that solution it is often hard to see a different perspective. Consultants risk suffering from a similar myopia. After-all, in a 9 month project how much do you really know about the differentiators between company A and company B. A seasoned consulting veteran may suggest that he has seen a lot but can he honestly say that he has seen it all? I doubt it.
Successful business in heavily competitive environments often differentiates themselves from the rest of the pack by having unique business processes and unique elements to the way they do business. Inevitably their IT solutions have grown up to support those unique differentiators and depending on the level of IT advocacy, the depth and taste for the proverbial corporate Kool-Aid and the degree of anxiety about business agility and the business environment. IT may have gone through many iterations of development and implementation to get the IT solution just right for the business. Implementing a standardized SAP solution may be very easy or incredibly difficult as those environments where the business managers and their supporting IT teams have convinced themselves and try to convince everyone else that they are very very different from the rest of their industry.
A good consultant who knows the SAP product, has been through a number of implementations, upgrades and enhancements and who has tackled similar business models, knows what is easily feasible and what has proven challenging to implement from past experience. When a company buys a consultant or implementation partner’s time, they are after-all hoping to leverage that past experience otherwise they may just as well invest in an off the shelf package or stay on their current IT solution. Unfortunately there still seem to be a great many people (customers and consultants alike) that still seem to think that due diligence is not required when evaluating options, or that everything will be “alright on the night” when they have their hearts set on a particular solution. Naively they state that “We’ll simply switch over from what we had to what we have just implemented and it will all be ok”. Those of us with a few more project battle scars know that successful implementations only happen either due to controlled scope, major business process reengineering, strong business advocacy/sponsorship and meticulous planning, preparation and training. These success traits remain true irrespective of whether you are implementing in a standardized, ‘vanilla’ way or implementing with enhancements no matter how good the consultants are. Your shiny new SAP implementation is likely NOT going to function the same way as your legacy system did and more importantly the way you use it and care for, feed and nurture it, is likely to be quite different to the way you use your home-grown system too.
Returning to the new SAP customer let me paint some context, they function in a relatively unique environment. Their business is not particularly agile and in fact, doesn’t really need to be because they are relative monopoly. They function in a regulated market so they have some restrictions on what they can and cannot do. They are geographically stuck, they can only do what they do where they are located and the barriers to entry in their market are very strong. They can’t simply relocate their operations and their customer base. The customers are a collective of utilities and heavy industries and are relatively exclusive to them and joined to their hip so to speak. If they were to shut their doors tomorrow, their customers would likely close down too and so they have a fairly onerous responsibility to their customers and the community as a whole.
Like some of those entities described earlier, they developed a number of solutions over the years to meet what they believe are unique attributes of their business and when the time came to finally retire their legacy system they struggled to find a perfect match. That said, they set their hearts on a limited installation of SAP and finally started the implementation. Initially at least everything seemed relatively straightforward, they constrained the project scope, reigned in their employee community and consultants, reengineered some business processes and poured away some of the flavored drink mix in favor of considering a different way to doing some of their business. In prototype, realization and at go-live everything appeared to work as expected however soon after go-live they determined that the very processes that would give them the increased granularity and detail that they sought in their reporting and analytics was proving to be an operational choker on their ability to get through the data processing requirements of the day. The end to end process in fact proved to be so onerous that the project sponsor served a deadline for process optimization failing which the implementation would be abandoned and they would revert to their original operational and technology playbook. Of course there were likely other issues at play also but more importantly the sheer magnitude of manual data entry and manipulation effort required to make the process work using standard transactions and in the framework of a standardized operational model simply proved to be unpalatable. This is hardly a surprising revelation to most of us. Any given SAP system supports so many possible ways of doing a given transaction to support the business, that there is bound to be complexity that sometimes translates into laborious and time consuming data entry.
Part of the challenge in these kinds of situations is of course the back breaking efforts that had possibly been made by IT in previous system incarnations to meet the very specific needs, wants and desires of the business and operational users; no rapid standard implementation can hope to capture all the nuances of ‘why’ the legacy system is precisely designed the way it is and a gap analysis between the systems always seems to be a strong point of resistance on the part of all those involved including IT themselves. Though an SAP industry-solution had been positioned as the optimal way to implement SAP, there were too many deltas in the capability vs. the requirement, for those responsible for that part of the business to feel comfortable with a full-blown switch to SAP across the board and probably wisely, so. In the finance and sales and distribution and inventory areas there were great strengths over the current capabilities of the home grown system and these were strong motivators for the initial implementation, but it looked jeopardized.
There is nothing wrong with change, if it is in the right direction” – Winston Churchill
Fortunately life is not always terribly awful just because a change is being introduced and as it turned out, much of the data that needed to be entered or posted was coming from environments that are fairly commonplace in almost every kind of organization, even this one. First off, the manufacturing and production processes were still coming out of the legacy system and this was not expected to change in the short-term, this data source was configurable according to the needs of the SAP system and development skills were available to facilitate this and more importantly, the outputs were portable and could be easily provided in a Microsoft Windows desktop environment as plain text, comma separated values or tab delimited text. The second data group, data coming from customers and being created internally to support the SD, FI-CO and MM needs were all making there way into Microsoft Excel in some way or another both before and after go-live. In essence, much of the data that was being created today to support the SAP system could be easily tweaked, repurposed and most importantly, recycled to achieve the same outcomes in the same powerful SAP solution but with the minor operational enhancement of implementing a Microsoft Excel to SAP integrated solution. Applying such an approach proved to be an acceptable concession by the owners of the purse strings over the possibly expensive further extension of the SAP system through legacy-integration or ABAP development to smooth the data flows. As is often the case, budgetary and time-to-delivery constraints pressured the business to consider proven and robust yet innovative approaches to achieving the same outcomes but in a highly accelerated way.
Using third party integrated solutions out of the family of SAP ECOHUB partners reassures new customers to SAP that these technologies are proven and certified for use with SAP systems. More importantly customers are assured that these solutions do not compromise on SAP security and the strength and integrity of the SAP transaction-based logical unit of work, risks that may be introduced by custom development or direct table access. From an operational and audit ability perspective these types of SAP ECOHUB partners’ tools present themselves as merely a turbo charger for data entry eliminating transcription errors, the need for expensive and protracted software enhancements or customizations or complex integration efforts. Users still need an SAP userID, need Microsoft Excel and the SAP GUI Client and yet within minutes, are able to quickly create relationships between Microsoft Excel data and the data that they need to see in an SAP transaction screen.
With this particular customer they were able to reduce the cycle time of an end-to-end business process in SD from 300 minutes to less than 5 minutes. Data entry errors through transcription and transpositioning were eliminated and the business reaped the rewards of being able to retain the new SAP system and simultaneously consider opportunities for the areas that they previously considered potentially to difficult to switch from their legacy environment to SAP. To my mind this represented a great example of responsible solution implementation and recycling of what was available and at hand. It would have been easy for the system integration partner to reflect back to the customer that they got what they bought. It would be easy to say that unfortunately, for more granular reporting and analysis capabilities, more data needs to be pushed into the system of record however in this instance it was clear that this was not about creating more work, rather this was about simply making it possible for all the information and data that already been created to be elegantly placed in a more useful environment, namely the SAP system.
Recycling what you have and making it work to best effect has to be the way forward both on a personal level and when it comes to system implementation, administration and maintenance. This is true especially when it comes to data there should be every attempt to maximize use even when some of the fundamental elements of the system architecture suggest that this is almost impossible.
Some articles that you may find interesting in this vein by Jon Richter and Scott W Ambler may pique your interest on how to do this with other technologies beyond SAP, from Automated Meter Management to really thinking carefully about how you get and use data and how you use open source.
The original version of this article appeared on SAP SCN here
