SAP's lack of openness is a huge problem, and will continue to hinder its development. Not only does the license cost millions of dollars, but then the enterprise that purchases it has to hire dozens to hundreds of expensive consultants to actually implement the behemoth. And if the company wants to actually understand how to use the system, they need to invest in expensive training sessions because any sort of public documentation (or documentation shipped with the system) is far too vague to actually provide usefulness.
I tend to think that the lack of openness is done on purpose - that is, SAP depends on its consulting partners to help sell its software, so they need an incentive to sell it (not to mention, SAP has a consultancy itself).
SAP has tried to evolve recently with new developments like HANA (mentioned in the article) and MII (tool used to connect manufacturing systems and provide real-time KPI dashboards), but without a more-open ecosystem that enables learning and innovation, it will continue to stagnate as modern technology overtakes it.
The biggest hindrance preventing companies from ditching SAP for a modern system is the fact that SAP is so complex and can handle so many business scenarios. Although it stands behind the curve in terms of technological innovation, it has decades of business specific functionality built into the system. That's the main reason, in my opinion, for why enterprises haven't jumped ship.
>I tend to think that the lack of openness is done on purpose
I doubt it. From my experience it's from outsourcing development to too many different groups with no coordination.
I worked on interfacing with a BigName's Hour Time Tracking module which takes hours to 8 decimal places. I submit the first payroll and hear it is imported with no errors.
Two days latter I get a frantic email asking me to resubmit because the Payroll module only takes 6 decimal places and was throwing out all the submitted hours. The systems are so large the consultants themselves cannot possibly understand it, let alone provide proper documentation.
I had a customer project two years ago: Import data that came out of SAP HR-PT into a MySQL database. HR-PT is the SAP personnel time recording system. This thing generates plain text tables with each entry having a fixed-width data type which has a peculiar German name. The 21st century solution for this would be an XML file. So the impression I got is that the whole SAP codebase seems to be stuck in the 1970s.
Working with this stuff is so complex that in Germany, it's an often-told inside joke in the IT industry that some small and medium sized businesses actually became insolvent by moving to an SAP-based system.
I've done somewhat similar work. I found it best ultimately to pull individual transactions -- as a text/report dump -- and then work them up in a combination of Excel with hooked in regular expression support and Perl and whatever else (i.e. for a front end interface). Excel provided a convenient interface for necessary manual sanitation. Perl provided enough speed along with flexibility and further pattern matching. Other stuff made the results accessible to accounting staff.
For my purposes, SAP was a giant data entry system. And a crappy one, at that, as one of the most important fields for my work was not a field, but one of an arbitrary number of entries glommed together in a free text field where only the maintenance -- or not -- of data entry conventions by the many individuals creating records provided any degree of sanity.
Thank goodness for regular expressions!
Separately, it's not just the "sexiness" of the problem at hand. It's that in typical SAP environments, the level of bureaucracy to get anything done is overwhelming. Your technical problems are far and away secondary; for example, just getting what you need on a report, any report, in a format you can at least begin with, is a six month ordeal.
Having your hands on the pulse of billion dollar divisions is kind of cool. The six or eight layers of wankers you have to go through, to accomplish this -- not so much so.
> Working with this stuff is so complex that in Germany, it's an often-told inside joke in the IT industry that some small and medium sized businesses actually became insolvent by moving to an SAP-based system.
I've heard of this almost happening; a malfunctioning label printer can cause an entire plant to shut down for weeks while consultants work to find the problem.
While SAP is not exactly cutting edge they have been adding some features to ABAP (their proprietary language) that you would expect to find in a modern language.
For instance, in your example you could use the CALL TRANSFORMATION statement to convert your table directly to XML.
The problem is that you can still write code as you would have done in the 1970's and SAP won't complain.
This is really a pity, because large companies can gather lots of interesting data. For example, my wife works for a large (European) oil company, which has been in the process of installing SAP (it only took ~ 2 years, with lots of SAP consultants paid at 800-1000 euro per day </sarcasm>).
Anyway, being the big company that they are they have lots of gas stations spread all over the country, in the best locations possible. But nobody is doing anything with that sales data. They could write some heatmaps, make some sales predictions based on how close a gas station is to a major road, see when things change etc. There's no incentive for doing that, because it will either involve re-hiring those consultants at 800 Euro per day or trying to train the internal IT people to modify/extend the existing SAP installation (good-luck with that!)
I think they'd need to license one of the bulkier versions of BusinessObjects to get the BI angle out of SAP. Not saying it couldn't be done in house but the mentality of using something like SAP doesn't seem to fit with the home-grown approach that well.
This guy pretty much gets it. Young programmers, particularly talented ones, are going to think that anything enterprise-y is just lame. Working at a startup feels like keeping it real in a kick-ass garage band. Working at SAP feels like playing triangle in a Gamma World City's Philharmonic. Even if it pays well and affords a modicum of respect, it just don't do.
It does pay well, which is why I'm often surprised there's not more demand from the younger generation. For example starting salary for a SAP consultant at a big firm starts at about $50k with some nice cooshy bonuses on top of that. Very competitive with that of banks actually. But bankers have the "promise" of making several folds of that if they just stick it out. I don't think the younger generation sees that promise in the enterprise world - even though I know many SAP in their 30's and 40's who are making more than enough to support a family.
The big advantage for SAP now is that they are the "right"choice for an ERP system and directors dont take chances.
But if companies notice that their philoshopy is just take as much money of their current customers instead of getting new ones, they can get in trouble as soon as another brand its "sponsored" by big customers.
They are actually startups tackling the SAP ecosystem with Open Source and/or Saas offers targeting small and medium businesses: OpenERP, BrightPearl, myERP.com
[+] [-] brendino|14 years ago|reply
I tend to think that the lack of openness is done on purpose - that is, SAP depends on its consulting partners to help sell its software, so they need an incentive to sell it (not to mention, SAP has a consultancy itself).
SAP has tried to evolve recently with new developments like HANA (mentioned in the article) and MII (tool used to connect manufacturing systems and provide real-time KPI dashboards), but without a more-open ecosystem that enables learning and innovation, it will continue to stagnate as modern technology overtakes it.
The biggest hindrance preventing companies from ditching SAP for a modern system is the fact that SAP is so complex and can handle so many business scenarios. Although it stands behind the curve in terms of technological innovation, it has decades of business specific functionality built into the system. That's the main reason, in my opinion, for why enterprises haven't jumped ship.
[+] [-] parfe|14 years ago|reply
I doubt it. From my experience it's from outsourcing development to too many different groups with no coordination.
I worked on interfacing with a BigName's Hour Time Tracking module which takes hours to 8 decimal places. I submit the first payroll and hear it is imported with no errors.
Two days latter I get a frantic email asking me to resubmit because the Payroll module only takes 6 decimal places and was throwing out all the submitted hours. The systems are so large the consultants themselves cannot possibly understand it, let alone provide proper documentation.
[+] [-] blumentopf|14 years ago|reply
Working with this stuff is so complex that in Germany, it's an often-told inside joke in the IT industry that some small and medium sized businesses actually became insolvent by moving to an SAP-based system.
[+] [-] pasbesoin|14 years ago|reply
For my purposes, SAP was a giant data entry system. And a crappy one, at that, as one of the most important fields for my work was not a field, but one of an arbitrary number of entries glommed together in a free text field where only the maintenance -- or not -- of data entry conventions by the many individuals creating records provided any degree of sanity.
Thank goodness for regular expressions!
Separately, it's not just the "sexiness" of the problem at hand. It's that in typical SAP environments, the level of bureaucracy to get anything done is overwhelming. Your technical problems are far and away secondary; for example, just getting what you need on a report, any report, in a format you can at least begin with, is a six month ordeal.
Having your hands on the pulse of billion dollar divisions is kind of cool. The six or eight layers of wankers you have to go through, to accomplish this -- not so much so.
[+] [-] arethuza|14 years ago|reply
[+] [-] mtrn|14 years ago|reply
[+] [-] bonzoesc|14 years ago|reply
I've heard of this almost happening; a malfunctioning label printer can cause an entire plant to shut down for weeks while consultants work to find the problem.
[+] [-] infinite_snoop|14 years ago|reply
For instance, in your example you could use the CALL TRANSFORMATION statement to convert your table directly to XML.
The problem is that you can still write code as you would have done in the 1970's and SAP won't complain.
[+] [-] paganel|14 years ago|reply
This is really a pity, because large companies can gather lots of interesting data. For example, my wife works for a large (European) oil company, which has been in the process of installing SAP (it only took ~ 2 years, with lots of SAP consultants paid at 800-1000 euro per day </sarcasm>).
Anyway, being the big company that they are they have lots of gas stations spread all over the country, in the best locations possible. But nobody is doing anything with that sales data. They could write some heatmaps, make some sales predictions based on how close a gas station is to a major road, see when things change etc. There's no incentive for doing that, because it will either involve re-hiring those consultants at 800 Euro per day or trying to train the internal IT people to modify/extend the existing SAP installation (good-luck with that!)
[+] [-] bchjam|14 years ago|reply
[+] [-] c00p3r|14 years ago|reply
[deleted]
[+] [-] jriddycuz|14 years ago|reply
[+] [-] mbesto|14 years ago|reply
On the flip side there
[+] [-] jcslzr|14 years ago|reply
But if companies notice that their philoshopy is just take as much money of their current customers instead of getting new ones, they can get in trouble as soon as another brand its "sponsored" by big customers.
[+] [-] mtgred|14 years ago|reply
[+] [-] edandersen|14 years ago|reply