What’s happening to the next generation of the SAP ecosystem?(techdisruptive.com)
techdisruptive.com
What’s happening to the next generation of the SAP ecosystem?
http://www.techdisruptive.com/2011/06/16/whats-happening-to-the-next-generation-of-the-sap-ecosystem/
21 comments
>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 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.
That's a good point - enterprise software is meant to be customized to a business, so maintaining a strong repository of documentation is difficult, if not impossible.
However, I've noticed that even some of the core functionality is pretty light on documentation as well (and it is typically written in German-English).
However, I've noticed that even some of the core functionality is pretty light on documentation as well (and it is typically written in German-English).
True, I've worked at OtherBigName, and whereas we did make as much money off training as software, the documentation mostly suffered because writing good and useful documentation of spaghetti code is really really hard.
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.
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.
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.
My impression of the Tier-1 ERP systems is that they are effectively software mainframes.
It depends on your definition. As I understand it, mainframes are a 2 tiered approach (client-server). SAP, like most systems today are built in a 3 tiered approach (client-application-server). So much of what changed in the mainframe days shifted most of the processing to the application layer, rather than logic purely built on a massive database.
The software is good in a sense that it gets it's job done. For example, should an application that completes financial transactions for one company be any different for another? This is why companies continue to buy SAP. Usability is a big issue from the client side.
The software is good in a sense that it gets it's job done. For example, should an application that completes financial transactions for one company be any different for another? This is why companies continue to buy SAP. Usability is a big issue from the client side.
"Tier-1 ERP" means the big boys (SAP, JDE, maybe MS Dynamics AX) not a software architecture.
A friend of mine once said: SAP sucks the blood out of the mittelstand.
"SAP is how Lucifer interacts with our world"
From: http://yro.slashdot.org/story/09/05/28/2143219/Allegedly-Rig...
From: http://yro.slashdot.org/story/09/05/28/2143219/Allegedly-Rig...
> 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.
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.
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.
> Big data is sexy. Ruby on Rails is sexy.
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!)
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!)
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.
On the flip side there
On the flip side there
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.
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
People get into SAP for the love of money, not software.
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.