LSMW. I wonder where that 4 letter acronym ranks in terms of frequency of use here on SCN. I'm sure it's in the top 10 even with stiff competition from SAP, ERP, BAPI, ABAP, and some others.
Why is that? Well, it's a very useful tool and comes up frequently in the functional forums. I remember when I got an email from a fellow SAP colleague introducing me to it. That was back sometime in the fall of 1999 but I know version 1.0 came out a year earlier and was supported as far back as R/3 3.0F. I dove into it and the guide that SAP had published and it was really great. I could see immediately that for basic data conversions, I could handle the entire conversion process without the help of a developer. Back in 1998, that was a fairly big deal and one that I'm sure the ABAPers had no problem ceding territory in.
Just a year earlier I was using CATT to do legacy conversion. It had a similar transaction code based recording mechanism, a way to define import parameters, and a loading mechanism to map a .txt file to those parameters. But CATT was not designed specifically for data conversion so it could be a pain to deal with. In particular, tracking load errors was very tedious which required you to do a large number of mock loads on your data to ensure that it was perfect.
My History with LSMW
Back in 1999, it was obvious to me that LSMW was a big improvement over CATT for a few reasons:
- I could incorporate standard load programs and BAPIs. Using screen recordings was no longer the only way to load data. I hate screen recordings. They eventually break and you have to handle them with kid gloves at times... you have to trick them into handling certain OK codes or work around validations/substitutions.
- LSMW allowed you to use screen recordings as a way to define your target structures. I love screen recordings! Why? Because, as a last resort, they let me change any record in the system using an SAP supported dialog process. If you can get to it manually at a transaction code for a single record, than you can create/change/delete that same data in batch using a custom screen recording.
- I could do the transformation within SAP rather in Excel. That saved a lot of time especially if I had certain transformations (i.e., a cost center lookup) that were used in different loads. Define once, use multiple times.
- I could load multiple structures of data. Again, this saved time because I didn't have to rearrange the data in Excel to force it into a particular structure format which might contain numerous fields that I had no interest in populating. That left my source Excel file relatively clean which was far easier to manage.
- Organization. LSMW had a way to categorize each load by Project, Sub-Project, and Object.
- No more developers! While the tool allows you to insert custom logic, it's not required to do so. If you know your data well enough and you have a typical legacy source file, there's no reason why a functional person such as myself can't load everything on his own.
Once word spread about LSMW inside SAP, it seemed that every functional consultant I worked with was using it. Eventually we started using it for purposes other than legacy data conversion. Mass changes, mass creation of new data that wasn't legacy related, etc. Other non-functional areas used it too; I've seen security teams upload mass changes to userID records.
This is how I Really Feel
But... I didn't write this to praise LSMW. Now, in the year 2014, I can't stand working with it. It's limitations have been bugging me for years and SAP hasn't done anything to improve it. My gripes:
- Poor organization. The simple Project / Sub-Project / Object classification is too limiting. It seems to be a quasi hierarchy of the individual LSMW objects... but why not release a fully functional hierarchy? If we had a real hierarchy we could use multiple levels, parent-child relationships, drag-n-drop, etc. There are some customers that don't use it that much and may only need a single level deep hierarchy. Others might need 5 or more. Either party is currently forced into using the existing 2 deep classification of Project / Sub-Project. What I most often see is a horrible organization of the underlying LSMW objects. That fault lies with the customers for not enforcing and administering this hierarchy. But if the tool made it easier to classify and organize the various scripts, maybe it wouldn't be as messy as I've come to expect.
- The prompts are inconsistent. This is a minor gripe but the function keys are different per screen. To read/convert your data file you navigate to a selection screen (a very limited one) and press F8 to execute. To read the contents of those data files within SAP, you get a pop-up window and have to hit Enter to execute it. No one limits the reading to a selection of records (or, very rarely do they) so I could do away with that prompt entirely.
- Another personal gripe but I'm so tired of the constant Read Data, Convert Data, Load Data... Whoops! Error! Change in Excel, save to .txt, Read Data, Convert Data, etc. The process has too many steps and I have to flip between SAP, Excel, my text editor, and my file manager (Directory Opus). Or, why can't I link directly to my Excel file and view it within SAP?
- There isn't a good way to quickly test or validate some basics of the data. I get that each area and load mechanism is different (i.e., BAPI versus screen recording) but there should be a quick way within the tool to better validate the data in a test format so that we know right away if the first 10 records are OK.
- Speed. I had some tweets with tammy.powlas3 this past weekend. She used RDS for an upload (Initial Data Migration Over, The Fun Has Just Begun). The upload of 600k records took an hour but I highly doubt that LSMW could beat that.
- The solution was great back in 1998 for the reasons I noted above. Back then I would happily double click between my source and target fields, assign rules, create lookup tables, etc. But it's 2014. I'd rather use a Visio type of tool to maintain my data relationships.
- Lack of Development. Here's the version we are running at my customer. 2004... seriously? No changes in 10 years? I recall the early versions of LSMW... v1, v1.6, v1.7... but I don't remember there being a v2 or v3. So how did we jump from v1.7 to v4 and what are the delta changes? Seems like some upper management mandated creative version management to me. My guess is that LSMW has been upgraded based on changes to WAS and to keep it along with ERP 5.0 to 6.0...but the product itself hasn't changed in terms of functionality. LSMW still feels like a v2 product to me.
My Biggest Gripe
But my biggest gripe isn't with the tool. It's how it's used by the SAP community.
It seems that every consultant I know uses LSMW as their go-to source for all data changes. I've walked into customers that have been using an LSMW to maintain some object for 10+ years!!!! How the heck can something like that happen? This is an area where LSMW's flexibility works against it... or rather, works against the customer's long term success with SAP. The problem here is that it allows us functional folks to quickly develop a 'tool' to maintain data. It's the quickest way to develop a solution on the Excel-to-SAP highway that accountants et al. need throughout the year. For a truly ad-hoc requirement to do just about any process in SAP based on data in Excel, it works fine. I don't have an issue with that and would recommend LSMW in those appropriate cases. But it's not a long term solution. Period, end of story.
Other Solutions
Mass Maintenance Tool
If you have a recurring need to mass change master data, you should be using the mass maintenance tool. Just about every module has developed a solution using this tool to change the most important master data records in the system.
Be Friendly to your ABAPer
Anyone heard of a BAPI? If you have a recurring need to upload transaction data or make changes to certain POs, sales orders, etc, or have a master record not in the list above, there is a BAPI that will do that for you. Get with your ABAPer, develop a suitable selection screen, get a test-run parameter on there, get a nice ALV based output report, and then get the tcode created. Done... that's a good solution using an SAP supported protocol that is far better, safer, consistent, and easier to work with than a screen based recording that dumps your data into BDC. In my opinion, if part of your solution has the letters 'SM35' in it, you've done something wrong.
Why would anyone recommend to a customer that they should use this crummy process (read data, convert data, display converted data...) as the long term solution for making changes like this? That's not a solution, it's a lame recommendation.
Final Word
LSMW and other similar screen based recording tools (Winrunner et al.) are flexible and it's tempting for people... and I'm talking primarily to the consultants out there that over-use and over-recommend LSMW... to keep going back to it. It's a useful tool but there are problems when you don't have enough tools in your toolbox to use... you're limited in options and you keep going back to what you know.
Have you heard of the phrase "When you have a hammer, everything looks like a nail". It came from noted psychologist Abraham H. Maslow in his 1966 book The Psychology of Science.
His quote is also part of something called the Law of the Instrument. A related concept of this is the notion of the Golden Hammer which was written about in AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis: William J. Brown, Raphael... The book covers the factors that come up repeatedly in bad software projects. Among them is what they call the Golden Hammer which is "a single technology that is used for every conceivable programming problem".
LSMW's time as my hammer of choice passed a long time ago. It's a useful tool and should be in everyone's toolbox but we shouldn't use it unless there is an actual nail sticking out.
UPDATE as of August 30th, 2016
Per OSS 2287723:
"As of S/4HANA 1511 (and higher)... The LSMW (Legacy System Migration Workbench) function is still available within SAP S/4HANA (on-premise edition) but not considered as the migration tool. LSMW might propose incorrect migration interfaces that cannot be used in SAP S/4HANA."
... and...
"The Legacy System Migration Workbench (LSMW) can only be considered as a migration tool for SAP S/4HANA using workarounds and careful testing for each and every object. The use of LSMW for data load to SAP S/4HANA is not recommended and at the customer's own risk."
- SAP Managed Tags:
20 Comments
