Clearly, SAP implementation promotes lock-in and this council is a prime example
East Sussex County Council is set to be at least six months late in appointing a vendor to replace its ageing R/3 SAP system, which is showing its age and struggling with performance issues. In June last year, the local authority on England's south coast said it would name a supplier to provide a software-as-a-service …
Done properly, no. Your data is in a DB to which you have full access and control, a complete set of APIs and 100's of companies and independent contractors who can get data in and out in any format you could wish for if you don't have the skills or google-fu to do it yourself.
Now if you chose to bring in somebody else to run it all for you in some third-party data
jail center to which you have no access to do anything more than basic user stuff then that's a problem for sure. But that's not an SAP problem.
Cloudy as-a-service is a whole different ballgame and quite frankly you get what you deserve.
<< Your data is in a DB to which you have full access and control>>
Really? You worked on a different SAP than I did back in the day. You could not even login to the DB with any credentials at all, because the SAP staff could refuse to support you on the grounds of uncontrolled changes to the environment.
And even if you manged to get a DB account (of course with limited rights), you started to run into those nicely "packed" rows where in their infinite wisdom, SAP decided to encode in a single database row the contents of one or more of their "entities", so you could not extract data with raw SQL but instead had to go thru the time consuming ABAP extraction.
The only fun part of all that was hearing how the SAP staff called these tables "encrypted", as if the information was in some form transformed to prevent you reading it. It wasn't. The reason for these "packed" tables was that SAP ABAP programs used nested loops instead of using database joins, fetching one row at a time from the DB for each one to many relationhip. This was a huge performance penalty in multi million row jobs. So instead of fixing that, the SAP engineers created yet another layer that avoided performing the join operation inside a loop by serializing the joined rows together in a single database row. Of course, that meant that you would not ever be able to read those rows with a SQL SELECT statement, but who cares about openess and integration. Also, why learn about database joins, or query optimization.
So much to have full access to the DB...
Given the sheer amount of custom coding that was put into their original implementation I'm not surprised they're still running it and haven't been able to replace it in 15 years. We never saw anyone else who did things the way they did.
Hint: Do not attempt to rewrite any complex piece of software like SAP to make it do basic HR and ordering stuff in a way which is unique to your personal twisted way of working. Especially when your implementation partner and even SAP themselves advise against it.
Anon 'cos of having some association with this monstrosity early in my SAP career. I still feel sorry for the good people who quit rather than have to face dealing with them. There were some of the most bitter and twisted creatures I've ever had the misfortune to work with in that place, and it seems their management have not changed.
I have spent half my career in ERP and the concept of "how custom?" is a perpetual bone of contention between customers and ERP vendors. This is not only the case with old monolithic ERPs like SAP but also with modern ones. In https://gtm360.com/blog/2020/05/27/when-erp-projects-get-derailed-by-silly-reasons/, I give three examples, including one of SAP-Lidl, where customer felt the extent of customizations was minor, vendor agreed to implement them, and the movies had a sad ending.
Local government accounting is so different form business accounting that they were mis-sold SAP in the first place. Given the amount of customisation required to get a usable SAP system often requires more man hours than writing a system from scratch the added complexity of Local Government finance and personal requirements only complicates things further.
By requirements stuff like every penny spent has to be traced back to a "resolution of the council" and anyone who voted for the resolution is personally liable for any mis-spending.
As for HR many council officers have legal responsibilities when carrying out there duties (others do not!) and just working out who is allowed to do what can be a nightmare (consider that "what" can involve removing children from a parent and putting them in a care home.)