Yup, exactly.
Got something to say or just want fewer pesky ads? Join us... 😊
Question for SAP users
- Thread starter Gwylan
- Start date
Yup, exactly.
Gullflyinghigh
Registered User
- Apr 23, 2012
- 4,279
I know of (and in some cases have been at) a few companies where the implementation of that festering dung heap has actually created jobs for both consultants (obviously!) and for customer facing staff who get to take the flack when customers start to notice...oddities creeping in.They used to say 'nobody ever got fired for buying IBM'. I wonder how many people have lost their jobs because they chose SAP?
Spearritt of the Albion
Member
- Jul 5, 2003
- 220
If you want to save money, buy yourself a Mainframe (yes, Mainframe!) stick a decent Database onto it, DB2 or Oracle would do the trick, and build your own bespoke systems to get out the results you want and not what SAP thinks you may want. I spent a lot of time in a team that was building a SAP HR system. I had to prove that what was being sent into SAP from our legacy system was the same as what came out after SAP had got it's sticky claws into the data. Impossible job! It's so complicated inside the box. Using DB2 we are able to deal with tables that have 1 billion plus rows of data on them and it processes them with ease. With GUI front ends, mainframe databases are becoming so much more attractive to use although, in this country, we are so much behind the rest of Europe as we plod on with SAP or SQL Server (that wonderful Microsoft database!).
Bring back the Dinosaur, bring back the mainframe!
Bring back the Dinosaur, bring back the mainframe!
FatSuperman
Well-known member
- Feb 25, 2016
- 2,920
I hesitate to answer this thread, but I work as an IT Project Manager for a large retailer, most of my projects are SAP projects. Obviously I'm not a fan, but if I'm being completely honest, the main problem with SAP is the way it is implemented and managed - not the software itself. It needs a lot of accurate, well-maintained data to get the most out of it. If you try to use it and are half-arsed about it, you're in for a world of pain. From a compliance perspective I wouldn't say it's any worse than any other massive ERP / large scale PLM system. Authorization again isn't the worst, if you've managed the roles correctly - although it's awkward for third-party access (vendors etc). I would say that the biggest issues we have are not on that list - change management and the associated risks. Included in that are keeping hold of subject matter experts in our particular *******ised version. We are of a size that whilst we want SAP because 'it's big and good for retail', we can't put up with it's idiosyncrasies, so we buy best of breed software and tack it around the edges.
:|
FatSuperman
Well-known member
- Feb 25, 2016
- 2,920
I don't disagree with the spirit, but that's exactly what everyone did 25 years ago. And those companies are now paying a heavy price, because everyone that wrote those applications are retired or dead. The attraction (if you can call it that) of SAP and other all-in-one off the shelf packages is that the support is a commodity skill, you can in theory just go to the market to get people. Whereas a custom application which is tailored perfectly for your needs, will need the management team to actually manage their resources and ensure that the proper service is maintained. Most people in middle management couldn't run a bath let alone a team.
- Jul 10, 2003
- 27,750
Couldn't agree more. If you are getting SAP, make sure you select the right version. A certain large organisation in the retail(ish) sector some years ago chose the retail version without any proper analysis. Turns out they should have chosen publishing because of their product structures. Mistakes at the early stage can lead onto massive customisation leading you to the same problems as above.
Once you have properly selected the right 'flavour' install it as close to vanilla and change working practices if needed. This way you can see massive benefits over bespoke development. Have done this, and although staffing costs may increase (because of changes to working practices), overall costs and maintenance can make huge savings.
(You won't believe what I used to charge for saying that slowly over 6 months
)
Seagull58
In the Algarve
Couldn't agree more. If you are getting SAP, make sure you select the right version. A certain large organisation in the retail(ish) sector some years ago chose the retail version without any proper analysis. Turns out they should have chosen publishing because of their product structures. Mistakes at the early stage can lead onto massive customisation leading you to the same problems as above.
Once you have properly selected the right 'flavour' install it as close to vanilla and change working practices if needed. This way you can see massive benefits over bespoke development. Have done this, and although staffing costs may increase (because of changes to working practices), overall costs and maintenance can make huge savings.
(You won't believe what I used to charge for saying that slowly over 6 months
I believe it! A UK based aero engine manufacturer spent more than 1.3 billion dollars implementing SAP and they have a team of more than 300 (mainly external consultants) supporting it from an office block near the iPro.
FatSuperman
Well-known member
- Feb 25, 2016
- 2,920
(You won't believe what I used to charge for saying that slowly over 6 months
Lots of us make great money due to other people's ridiculous choices, but you know I really would rather earn a bit less and not have to work with such ill-fitting solutions. I was drafted in to help when a company had integrated two SAP instances together (each running the entire business for separate continents), the team had done a fair job but the parts they missed caused severe issues - a massive rescue operation was needed. I had to spend 3 months in some offices near Heathrow, running teams in Hong Kong, India and China who were there just to keep the business teams from rioting whilst we tried to fix the problems. You've not lived until you've sat on a conference call in a miserable office block and watched the sun rise, set and then rise again. Three months, it almost killed me.
This, this and this thrice. I recently implemented a replacement CRM system and the data in the original system was dire. It had to be cleaned by hand - all 50,000 customer records !!! I've also implemented a new financial system where the original data was so nonconforming that the business had to spend thousands on buying an ETL package. If companies put more effort into data accuracy then they would save a lot of money.
- Thread starter
- #31
There have been some really useful comments on this thread - thanks to everyone.
Question for Larus and Westdene Seagull: how should companies ensure data accuracy/integrity. That seems to be a key issue when it comes to SAP (or any ERP system). What should they be doing to stop 50k records having to be cleaned by hand?
Question for Larus and Westdene Seagull: how should companies ensure data accuracy/integrity. That seems to be a key issue when it comes to SAP (or any ERP system). What should they be doing to stop 50k records having to be cleaned by hand?
A good question !!! There's no silver bullet but key processes include :
> Try and purchase applications that force the data to be of a set format - as a simple example, don't allow free text in a date field. I've no idea if SAP provides for this though.
> In my example mentioned previously the company had brought a load of data but rather than check and clean it before loading it they just loaded it.
> If you want to import lots of data regularly then consider using an ETL tool. Extract, Transform and Load. Then your DBA can write data checks into the process and the ETL tool will 'make' the data correct.
> Any DBA worth their money will be able to write scripts to do checks of data already in the database ( well they can when SQL and Oracle is in use ).
The problem is that keeping your data clean takes time, money and process - and that process being enforced ! Something senior management don't often understand ( or want to understand ).
- Apr 13, 2015
- 3,857
This is an odd thread... I actually build, amongst others, SAP test environments for a the insurance division of a well known bank.... Unix host, Oracle databases... mostly supporting claims.... it's dull and tedious... I know the technology... have no idea about the business functionality.
Sent from my SM-G920F using Tapatalk
Sent from my SM-G920F using Tapatalk
- Thread starter
- #35
Thanks - that's useful for my data integrity,
Now, does anyone know anything about licence management or SoD?
thedonkeycentrehalf
Moved back to wear the gloves (again)
- Jul 7, 2003
- 9,340
I have worked for two large organisations who use SAP. In both cases, one of the major issues is that because SAP seem to have an add on application for just about every business sector and requirement, senior management adopt the 'Emperor's New Clothes' approach where the SAP salesman will say it does what they want and they agree like lapdogs because they have lashed out on an expensive system and want it to do everything. They then find out that these add ons do not meet their business need but are too stubborn to admit this so leave everyone to try and make it fit.
SAP are also very arrogant because of their dominant position. As an example, I was part of a group making decisions on a new customer facing solution for a large multi-national company. Three other companies responded in full to our requirements documents, sent senior people along who really knew their stuff to the meetings and showed that they really valued our business. SAP failed to send through the information we wanted in advance, they couldn't agree which country should send in the sales and technical teams, the country who did turn up were missing their key man as he had a day off (another companies rep interrupted his holiday to fly in for the day) and finally, failed to demonstrate the actual solution.
Most of us in the room were appalled at such a response and scored them very low. However, our SAP technical team scored them very high. They said it was because it would be easy to implement - no consideration for the users. When we challenged them as SAP hadn't actually shown us a solution, they tried all sorts of excuses but eventually caved in and agreed to get the best of breed solution rather than the SAP vapourware.
SAP are also very arrogant because of their dominant position. As an example, I was part of a group making decisions on a new customer facing solution for a large multi-national company. Three other companies responded in full to our requirements documents, sent senior people along who really knew their stuff to the meetings and showed that they really valued our business. SAP failed to send through the information we wanted in advance, they couldn't agree which country should send in the sales and technical teams, the country who did turn up were missing their key man as he had a day off (another companies rep interrupted his holiday to fly in for the day) and finally, failed to demonstrate the actual solution.
Most of us in the room were appalled at such a response and scored them very low. However, our SAP technical team scored them very high. They said it was because it would be easy to implement - no consideration for the users. When we challenged them as SAP hadn't actually shown us a solution, they tried all sorts of excuses but eventually caved in and agreed to get the best of breed solution rather than the SAP vapourware.
Bad Ash
Unregistered User
The questions you're asking are not really aimed at the average SAP user, but rather system administrators I'd say.
When you mention authorisation (and later SoD), I assume you're talking about the roles assigned to users (we refer to that as SAP Security) and segregation of duties? That's a specialization within SAP . I'm a SAP Finance Manager and while responsible for the Finance roles, they are built by the SAP Security team. That team also run a tool called GRC to check a role for SOD issues, based upon sets of standard and customised rules. Customised rules would be required for custom transactions / programs. The checks are a complete pain in the arse if I'm honest. We did an exercise to reduce the conflicts the GRC tool reported, and many of them seemed to be invalid. But anyway we ended up removing losts of transactions from the roles and having to create quite a few new roles. The users just ended up requesting more roles, so the end result was that they ended up with pretty much the same transactions. So while we check for conflicts within a role, we don't check for conflicts across the roles assigned to a user, well not often.
One large weakness that I've seen with SAP roles, is that when the users has more than one roles they can get unintended access because the authorsation to the various objects is checked individually across all the users roles. The best way I can describe it is:
Role A gives the user transaction X for Company code 1.
Role B gives the user transaction Y for Company code 2.
If you give a user both roles A & B, they can run transaction X for Company Code 2, and transaction Y for Company Code 1.
At least that's what I've been advised by the SAP Security team!
When you mention authorisation (and later SoD), I assume you're talking about the roles assigned to users (we refer to that as SAP Security) and segregation of duties? That's a specialization within SAP . I'm a SAP Finance Manager and while responsible for the Finance roles, they are built by the SAP Security team. That team also run a tool called GRC to check a role for SOD issues, based upon sets of standard and customised rules. Customised rules would be required for custom transactions / programs. The checks are a complete pain in the arse if I'm honest. We did an exercise to reduce the conflicts the GRC tool reported, and many of them seemed to be invalid. But anyway we ended up removing losts of transactions from the roles and having to create quite a few new roles. The users just ended up requesting more roles, so the end result was that they ended up with pretty much the same transactions. So while we check for conflicts within a role, we don't check for conflicts across the roles assigned to a user, well not often.
One large weakness that I've seen with SAP roles, is that when the users has more than one roles they can get unintended access because the authorsation to the various objects is checked individually across all the users roles. The best way I can describe it is:
Role A gives the user transaction X for Company code 1.
Role B gives the user transaction Y for Company code 2.
If you give a user both roles A & B, they can run transaction X for Company Code 2, and transaction Y for Company Code 1.
At least that's what I've been advised by the SAP Security team!
- Jul 10, 2003
- 27,750
I've had exactly the same. They told me that they would bring in their specialist team for that area from Germany when they had been shortlisted. It was only when I told them that they weren't near the shortlist that they pulled their fingers out and bought the team in. I've recommended them, other ERP suppliers and various mixtures of packages and bespoke over the years, depending on requirements. But that is the key, you must invest huge amounts in understanding and documenting your requirements before you go near the markets. It's also quite good to tell the suppliers that if they try to go over your head (plc boards etc) that they will be disqualified from bidding. All is fair in Love and Software.
One other point on data integrity - all systems work with and create corrupt data. Only problem is no two will work on the same set of corrupt data.
Disclaimer - I retired 7 years ago, so this may all be completely out of date or complete bollocks
larus
Well-known member
Following on from Westdene Seagulls points.
Make sure the DBA(s) understand the business process/data architecture. The days of 'Super Users' within departments are over and now the real expertise lies within the IT Business skills. You need someone who understands both from the business process perspective and also database environment how the data works and also, the implications of making changes. Users don't understand the implications of what they do, all they want to do is there job (usually).
There's a variety of roles that DBA's do. They can just do the administration from a technical/security perspective, or they can be involved in understanding the contact of the data. The ones who understand this, will be the ones who will be looking to write verification scripts. The important thing is in the methods you adopt once you encounter errors/issues in the data. Some people (who really pee me off) will just fix the data and move on. Me, I try to interrogate the processes which could have caused this to occur, get to the root cause, and then adjust the process to eliminate these errors. More time consuming, but the long-term benefits are huge. It also reinforces to the users the importance of data accuracy. You find an issues, demonstrate the problem, and then demonstrate the fix. They see the impact and usually buy in to the revised process. I have a view that most people take pride in their work, so if you can get them to take ownership of their data, they will ensure it's maintained accurately. But, the company needs to be prepared to invest to provide additional reporting/tools/software to help the users.
I've been doing long-term work for 2 main customers now (about 100 days p.a. each), there's always so much more to be done to improve the ERP systems. But, the cost savings long terms can be high. For example, I developed an Intranet based engineering portal front-end to our ERP system which took maybe 5-6 man weeks (at a guess), and the engineering manager reckoned that it saved him needing to employ another engineer at a cost of say £40k p.a. (est.). That's an on-going saving. There's lot's more bolt-ons I've created for them too.
Yes, I'm very well paid (over 600 per day), but look at the potential benefits.
One last point. Try to eliminate information islands and drive your KPI reporting from the ERP data. Stop people downloading data to produce the KPI's and maintain their own access database for example.
I have a 'friend' who is a SAP Security and GRC consultant.
He wants to know why he would give free information to a journo who has asked what are the issues with SAP Governance, Risk and Control but doesn't seem interested in the benefits?
Would you ask "Any bakers out there want to tell me what's bad about bread?"
He wants to know why he would give free information to a journo who has asked what are the issues with SAP Governance, Risk and Control but doesn't seem interested in the benefits?
Would you ask "Any bakers out there want to tell me what's bad about bread?"