Perils of Over-Customizing SAP-Broken Reports

I've been around clients for some great discussion on the perils of over-customizing SAP lately. I hope to collect some of the lessons learned here for your reading enjoyment and career enrichment.

Here's a comment made by a country sales manager at a meeting I attended in May 2007.

"They told us that the new SAP system would have over 160 reports out-of-the-box that we could use to run our business and we didn't plan on having to create a lot of custom reports. Now they tell us that's not true. Almost all the out-of-the-box reports are broken. Almost every report we need must be a custom development."

It seems this company made some customizations to their base SAP system (ECC) when they were only operating in a only single country and were focused only on a transactional, commodity type business model. They then moved into multiple countries and began to look closely at big, relational customers and value-added services. To support this, they planned to create a new CRM system running on top of their existing ECC. They were not happy to find out that their legacy of prior ECC customizations "broke" a lot of the standard SAP reports.

I'd love to hear from other people who might have an SAP over-customization lesson to share.

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.

Powered by Podbean.com

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

On War and Aggessive Project Schedules

I recently attended a 3-day "Business Design Assurance" or BDA held by my client. On the first day it was clear that there were still a lot of unresolved issues and the desired delivery date of the rollout to the first country was a risk. There was a lot of talk along the lines of "we can't go live without XXX!" A certain Senior Vice President could not attend the second day of the BDA but had the following as a message posted on the wall when everyone arrived for the second day of discussion.

"A good plan today violently executed is better than a perfect plan next week!"

General George S. Patton

(Dec 2007) English not your native language? I've begun making podcasts of popular posts and they are available at http://artsciita.podbean.com/. Listen online at that URL, with the MP3 player below, or subscribe to the podcast using the RSS feed and listen with your favorite MP3 player.

Powered by Podbean.com

Death of the Packaged Application?

Judith Hurwitz says that SOA could result in the end of packaged applications as we know them. Check out SOA and Unintended Market Consequences - Weigh In - weighin - CIO

What's in a Name? SAP Gives Up on ESA and Adopts SOA Terminology

I heard today that SAP was abandoning their name "Enterprise Services Architecture" name (see this ESA post from 2004 and Breaking Down SAP's ESA Strategy) in favor of the more widely used term Service-Oriented Architecture (SOA). I decided to do a little Googling tonight to check it out. I could find no official announcement about the name change (I didn't look all that long) but many of the top ranked search results now seem to come back with the term "Enterprise SOA" (see SAP's Enterprise SOA Adoption Program). It is a little amusing that on one SAP page pointing readers to white papers, both terms are used.

I don't know how significant this really is, but it appears they are grudgingly adopting the terminology everyone else is using.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

SAP Projects and the "Big Bang" Theory

A fellow IBMer saw some of my previous posts about navigating the SAP maze from a custom development point of view and sent me an email basically asking the question "Can SAP projects be iterative? All the ones I've ever seen always seem so 'big bang.'" The more I thought about his question, the more I realized how reasonable the question seemed to those of us who've been building custom applications. After all, how many small SAP projects have you seen? How many have put something in production in 3 months? Don't most of them have budgets in the tens of millions of dollars (or even more)?

I decided to pose his question to a "real SAP consultant" I met recently. She claimed that SAP projects can be iterative. An project can cycle thru multiple iterations of the ABAP programs used for point-to-point integration with SAP (the old style integration pre-dating XI) and companies can and do gradually add new modules to their SAP environment. (This is probably more incremental vs. iterative).

I challenged her "don't the customization done at the beginning of an SAP project drive the generation of database schemas? Aren't these database schemas hard to change?" She said she typically isn't involved in that kind of SAP setup but that it could be done. There was, however, a catch. Such a change would probably require some kind of data migration project associated with it to move data from one schema to another. My gut tells me these data migrations are almost always painful. There is a reason IBM acquired Ascential a while back. The phrase Master Data Management (MDM) is familiar to all SAP consultants. If your client is looking at SAP, you'll get familiar with it too.

I think this may shed light on why SAP projects appear to be such a "big bang". Most companies do not want to support more than one system of record simultaneously. (The "E" in ERP stands for "Enterprise" so otherwise you are taking the "E" out.) They want SAP to take over all of whatever it is doing (for example the order to cash process). Otherwise you get into a need for the new SAP and the old legacy system to exchange a lot of information to keep each other "in synch" with what they are doing. Everyone these days wants their data up-to-date in real time so that probably means real-time synchronization.

I know of a company facing exactly that kind of decision. They don't really like the idea of rolling a new system out across the whole company. They'd prefer to roll new capabilities out to a single line of business first. But... each line of business shares a lot of the same customers and dealers. They often share warehouses. Shipments to customers often contain a mix of products from different lines of business. With today's legacy systems, customer can mix products from different lines of business on the same order. Imagine the implications of changing the order to cash process to a new SAP system and rolling it out to only one line of business at a time:

• Do I track inventory in two different systems?
• How do I load a truck at the warehouse if the shipment includes products from both systems?
• How do I keep up with vacant storage bins in the shared warehouses if the inventory is split between two systems. Do I draw a line down the middle and and disallow putting line of business A's inventory on the line of business B side of the line?
  
• How will I generate the pick list for the people that load the trucks? Will they have to work from two lists? How do yo make sure it'll all fit on the same truck?
• Dealers don't have to split orders by line of business today, will they have to split their orders into two separate orders tomorrow while we're in transition?
• Will customers have to check the status of different line of business orders separately?
• Will my dealers get a single invoice with all line items like today? or will they get two separate invoices, one for each system?
• Will dealers get a single monthly statement?... or two separate monthly statements?
• When a dealer visits the B2B website today they can order products from different lines of business from one screen. In the future, will they have to go to one screen for one line of products and to a different screen for the others?
  

So, the choices are clear (or is that murky?):

• Offload the data integration onto your employees and customers; making them deal with separate orders, separate shipments, separate invoices, separate statements, etc. OR
• Spend millions on middleware solutions to broker all transactions so that they all look to the external customer like there is a single back end system OR
  
• Put the "E" back in ERP and don't even try to roll out an order-to-cash process until your whole business (Enterprise) is ready.
  

Which would you choose?

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

How to Talk to an SAP Consultant (If You Must)

I discovered via last week’s post SAP Disrupts Everything that I am not the only one in the I/T Architect blogsphere who is craving information on the integration of SAP with the rest of the information technology world. It was by far my most popular post ever. (Thanks to everyone who visited and special thanks to those of you with widely read blogs that directed others to this post.)

I am just becoming aware that the package-world people and SAP people in particular don’t communicate very well with us custom development types.

A prime example is the use of the word “requirements”. You’d think this was an almost universally understood word in software development. Well... maybe not. When I think of requirements, I think of things like the answer to “What do you want your system to do?” or maybe a collection of use cases. Oh.. and don’t forget non-functional requirements like “if the database crashes we need to be able to recover in 4 hours or less”.

I am still trying to figure this out but it seems that to someone who has grown up in the SAP space, the word requirements takes on a very precise and specialized meaning. This is not a term used in the same sentence with open-ended, green field questions. SAP has something called a “business process hierarchy”. At the top level, this might include something like purchasing. At the next level down purchasing is decomposed into purchase requisition, purchase order, etc. At the next level down, it would be further decomposed into things like release of purchase orders, transmission of purchase orders, scheduling agreement delivery schedule, transmission of scheduling agreement, etc. This decomposition continues down to an excruciating level of detail, perhaps 6 levels down. A “requirement” then is which of these many low level business process are chosen out of the SAP-approved business process hierarchy which are identified as “in scope” for the SAP implementation in question.

In the newer versions of SAP, all of these many different business processes are loaded into a tool called Solution Manager which visually provides a hiearchial way to browse these business processes. This tool also provides a way to load things like the user roles and client’s organizational hierarchy. Maybe requirements becomes a slightly bigger term encompassing all the “in scope” items in Solution Manager. Not 100% on that so I’m open to comments or correction.

I’ll try to point out more examples of SAP-specific language and nuance as I bump my head against them.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

SAP Disrupts Everything

I spent the last three days as what seemed like the only custom application development guy in a sea of SAP consultants for whom the world revolves around their favorite package. Since a client of mine is likely going to bite the bullet and go down the SAP path, I had begged my management for some “just in time” training in SAP. I had no illusions that with three days of training I could actually implement anything related to SAP. I just hoped to get to the point I could discuss topics intelligently with the SAP folk who will likely be showing up soon.

The more I listened (and occassionally dared to show my ignorance via an occasional question), the more disruptive SAP’s entrance into the SOA space seems to get. This is not to say that being “disruptive” is all bad. (See my post “A Culture of Innovation or Not” for some discussion about corporate culture and innovation as in “Wouldn’t it be fun to work at a disruptive company like Google?”)

Here are some examples of the kind of disruption in the software industry and SOA in particular that I’m talking about:

• There are numerous releases of SAP which are simultaneously supported by SAP at present. Many companies got up and running a while back and are faced with the prospect of trying to migrate to newer versions when they have customized SAP heavily. (Customization may need more custom work to get them running on the new version.) At the same time, SAP is raising the price of maintenance support of the old versions it doesn’t want to have to support anymore. In the very near future some of the oldest versions won’t have support at all except to pay SAP by the hour.
• Does a back-level SAP customer take the “safe” route and upgrade to a non-SOA-enabled version whose support runs out one or two years later? Or do they risk larger changes to their infrastructure and leapfrog into the latest and greatest version SOA-enabled versions.
• People with skills implementing the SAP using the “old style” BASIS and ABAP will likely have to learn that the latest and greatest versions are based on a J2EE application server. Similarly, the old SAP “modules” seem less and less relavant as SOA-enablement facilitates business processes that cross the old boundaries of modules with acronym names like SD, MM, PP, and FI. The list of digraphs is a lot longer than that.
• IBM is hiring SAP consultants by the way. A huge number of SAP accounts are on those back-level releases. Many want or need to upgrade. The SAP time-bomb is ticking.
  
• People like me who already have J2EE skills might like the idea of having our skills more readily transferable into the high-demand SAP space as SAP adopts the J2EE application server technology.
  
• People like me who already have J2EE skills need to remember that unlike ABAP, there are armies of J2EE-ready programmers in places like India who will also be embarking on an SAP journey soon. IBM announced a $200 million investment in exactly that kind of thing not too long ago. Granted, not all of that is directed at SAP projects but I believe IBM is SAP’s largest integration partner. Read between the lines.
• (only slightly off topic) IBM is still hiring J2EE types by the way ... and hiring them in the US. In fact, I got an email a week or so ago from my organization in the US outlining how many people we’ll have to telephone screen, how many we’ll have to invite for face-to-face interviews, how many offers we’ll have to extend, etc. to meet our hiring goals in the US for the second quarter alone! (I thought it was a pretty big number.) Did I mention you generally have to be willing to travel? Also, as a sign that the job market for people like us is pretty good... not one person bothered to send me their resume as I offerred in “IBM to Invest $1 Billion in On Demand.”
  
• People who have grown up doing point-to-point integration between SAP modules will need to jump into a new projects where point-to-point is discouraged and the new paradigm is to use the XI infrastructre as a broker (that smells a lot like an Enterprise Service Bus or ESB).
• Soon, it won’t be just the J2EE SOA crowd who will be thinking about visually stringing together discrete services to form larger, coarse-grained “composite services.” An army of SAP consultants will soon be trying to modify the out-of-the-box SAP processes by inserting new, client-specific steps. (Gasp) Will they be doing it in visual modeling tool? And which tool will they be using? ARIS for SAP Netweaver? WebSphere Business Modeler? WebSphere Integration Developer?
• This impacts more than you think. How does an I/T architect estimate how long it will take to complete an SOA-enabled SAP project? Will previous estimating guidelines apply? (No!) Will the best practices be different? (You bet!) Will the methodologies have to change? (Absolutely!) How will you test an SOA-enabled SAP solution? (Hmmm..)
  
• And don’t forget the .NET crowd. Project Mendocino is out there exercizing integration options between things like MS Outlook Calendars and SAP.
• With all the buzz surrounding whether an SAP customer should use Netweaver XI or IBM WebSphere products to integrate their systems, it is easy for some of the smaller integration vendors to be ignored.

Is all that disruptive enough? Or do I give SAP too much credit?

There are lots of new skills that will have to be learned by lots of people. There are lots of big impact decisions to be made. Lots of companies will need expert help. I repeat the mantra from a previous post.. its a great time to be an I/T Architect.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Get Ready for n-Series

I just finished three days as practically the only non-SAP consultant amongst about 200 of my SAP consulting bretheren from IBM Global Business Services (formerly IBM Business Consulting Services). I must say that it was well worth my time and as I have the bandwidth to blog about it, I will add more posts about what I learned, my observations of the SAP space as it affects enterprise architecture, SAP and SOA, WebSphere vs. Netweaver XI, and maybe a few predictions about the future of the SAP space.

Let me start my run of blogs on this topic with hardware, however. Perhaps you’ve heard these platforms:
• z-Series (the mainframe)
• i-Series (AS/400 midrange)?
• p-Series (IBM’s unix platform running the AIX operating system)
• x-Series (IBM’s Intell-based servers used for both Windows and Linux)

But... have you heard of “n-Series”? Neither had I. n-Series is the IBM brand for a storage appliance. This appliance has great usefulness in the SAP space where customers are constantly making copies of databases.

Since it is an appliance, it plugs into the customer network with its own operating system embedded in it. This frees up resources on SAP database platforms for other things.

n-Series also offers FlexVol™ which decouples storage space from physcial disk drives. With it “system administrators can dynamically assign storage space to a user from the available pool of storage resources based on that user's space requirements. This flexibility can help your organization simplify operations, improve utilization and efficiency, and make changes quickly and seamlessly.”

n-Series also offers Flex Clone™ which provides the ability to quickly make copies of databases. In the SAP space, customers are always making copies for testing, promotion, exporting via batch processes, etc. “FlexClone technology generates nearly instantaneous replicas of data sets and storage volumes that require no additional storage space. Each cloned volume is a transparent virtual copy that can be used for enterprise operations.” Apparently, the embedded operating system keeps track with which blocks of data in any given file have changed. It provides virtual copies or “clones” for data blocks which still match the original copy. It senses when a user/system has made a change to data block within a virtual copy and only then allocates new disk space. The result? Faster copies, less physical disk space required, and faster backup and recovery.

Click here for more information on n-Series

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

I've Gone Over to the Other "Dark Side"

In previous posts I have made some references to "going over to the dark side" whenever I talked about marketing types, salespeople, and selling in general.

For an application architect who has taken some pride in creating exactly the custom application solution a client needs, there is sometimes another "dark side" to be reckoned with. I'm talking about our fiends and colleagues who specialize in packages. Not all of us who've made a career in custom development like the prospect of our favorite clients looking at SAP, Oracle's ERP, Peoplesoft, Siebel, Reteck, or one of the other popular packages. It seems those "package types" speak a different lingo. Frankly, we are jealous of the salaries these specialists command. We wonder whether "packaged enabled business transformation" could be any fun compared to creating a solution from scratch. We wonder if anybody will ever do a big custom development project ever again. We fear we had better jump on the bandwagon.

Well, for a short time at least, I have gone over to this "dark side." For three days, I get to spy on my colleagues in IBM's SAP consulting practice and attend some of their training. One of my clients is seriously looking at replacing some legacy systems with SAP. In particular, I am focusing on the project methodology they use and the middleware issues related to connecting SAP with non-SAP systems. I'll get to spend some time learning the different approaches to this problem proposed by both IBM Software Group and (gasp) SAP's NetWeaver and XI.

Its too early yet to see how this is all going to turn out but my friends in the SAP space know how to do training. Below is the view of Baltimore's Harborplace from my hotel window. Its a tough job but somebody has to do it.