SAP is Dumb. 

Very high learning curve.

@@4.0Solutions not really I have use SAP Hana for almost 4 years for Supply Chain portion of it and I know my way around SAP. The difficult part is data integrity, with the correct data SAP is bible.

SAP is not user-friendly at all!

I guess it is not for dumb people… just saying

Lol, that's totally killing me 😂😂

Not Software Against People? :D

Management are really dumb. Just look at Ford. Signed away all the intellectual property to Bosch in the car's control modules. Now they can't integrate with any of that data. Jim Farley admits this was a huge mistake.

You cannot forecast the future of the business in SAP because the events of your business do not live in SAP, what is in SAP is merely an abstraction of the business. You are wrong.

Use open Source iDempiere instead of SAP.

This is one of the reasons 4.0 Solutions is a proponent of building a Unified Namespace of normalized, contextualized data via the use of pub/sub brokers to collect and exchange data from the plant floor with office systems (SAP) data.

You should really not bring SAPGui to the shop floor. On the SAP side you only need one technical user and then you trigger your business processes through it from your IoT Platform. No need for licensing additional business users. The SAP PM module does have some APIs (if you are using one of the newer SAP versions) but most likely you need to add some using ABAP/CDS.

@@fluffyunicorn7155 That is a common misconception, User Accounts are never mentioned in most license agreements or nobody would pay millions in licensing and simple channel all use via one user account or front end facade. Terms are always based on end User access, which is always defined as real People and/or Devices. To use a single user service account to multiplex/aggregate client communications to a licensed server product was a legit way of minimising license costs in the early days of IT about 25+ years ago, but every major application vendor learned real quick and updated licensing terms to include Indirect Client User licensing. Since then channelling clients (people and/or end device) via a single licensed user account, or having everyone login with the one shared account etc besides being real bad for security, does nothing to reduce the commercial license requirement for every human or thing sending data streams to or from the licensed system. I have a long history in IT and have directly engaged SAP, Microsoft, Oracle and other at length many times on this very important topic, the result is always the same it does not matter how any intermediate internal or external system the data flows, or what technologies or protocols are involved including MQTT server/brokers running on AWS or any number of other systems chained together, if the data flow automatically cals are required. Given the connectedness of the modern enterprise, the only things that avoids a open ended unlimited requirements is either the relationship of the person to the company (employee vs customer vs public etc) or ownership/control of the device/thing, or having a human/person perform a manual even, which could be as simple as pushing a button to triggering a schedule batch integration, but when data flow is fully automatic end 2 end then all end devices and people need to be accounted for and licensed. People often say to companies like SAP that's unfair, and SAP doesn't own their data but their business owns the data etc, the response is that yes the company still owns its data and therefore could choose to manually export it all and load it into another system, but while its in their system (SAP ECC v6, Oracle, app hosted on Windows Servers etc) then any client access to the data is effectively utilising licensed functionality and must therefore be licensed under the EULA terms for that product. Depending on the server product some can be capacity licensed (like MS SQL) but most of the core applications (SAP)/platform (windows server, O365 etc) have an essential CAL requirement and that is a big constraint when wanting to achieve the long term holy grail - to unify all things for boundless information flow. You could create a Unified Name Space, Operational Data Store etc using tech stack with more flexible licensing and use it in isolation, like a BI platform, but its very hard in a modern to isolate data and of course goals against digitial/i4 principles, and the moment there is a data channel connecting that infrastructure to the rest of the organisation, those 10'000 of PLC and other things will usually need CALs for every licensed enterprise system data flows into or out of across each of the many licensed products in the company. No architect likes this, but its a major constraint to architect around. The one technical user account approach does not avoid the need for licensing additional business users or the devices that send the data/message triggers be it direct via SAPGUI or indirect via MQTT broker or any number of other system. This is not a technical issue, one could simply ignore it the EULA document and things will function just fine but its a commercial legal/risk and big issue while legacy enterprise technologies are part of the mix. This still applies to many cloud platforms (SAP hana, O365), hana improves vs onprem SAP 6, by avoids the need for people from other organisations to be accounted for and licensed, but does not avoid the need for such end user licensed for all access employees/onsite contractors or company owned controlled/devices.

Because you need edge connecvity to process the events