from what i've learned in like an hour, SAP isn't for small to medium businesses, but large businesses to communicate between departments. I assume for businesses that trade on the NYSE.
@@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.
Remember computer systems are built from the process of the mind: Cluster=You, Process Core=sections of the brain, Table=left side or right side, Field=body part, and crosswalk/handoff=handshake. Nice to meet everyone. Hope everyone is having a wonderful day.
So if SAP is Dumb, HOW DO you run and manage the information such as MPS and Inventory and Operational performance at scale? Or are we processing a few orders only? SAP is not the only platform but requires defined processes and discipline, which numerous companies lack IMO.
SAP is not actually SAP - in fact, it's one of the most, if not the #1, ERP nowadays! At the end of the day, most people I know that dislikes it is mainly because on how the solution was implemented - not the software as it's. The problem relies mainly on people not committed to the transformational project, bad project management, almost non-existent change management, and so on. The software can cover, via standard + developments, 99% of businesses requirements in the market. For the 1%, there are other solutions that can integrate with it.
one big issue I see with integrating internal manufacturing data with SAP ERP is because SAP need indirect licenses for every user or device on the floor, which can be hundreds of users, or thousands of devices. Having a few people at each plant manually interface with SAP via SAP GUI limits it to a few people that can counted and licensed. Integrating the stack from the shop floor, MES, SAP and cloud means an almost uncountable number of indirect data flows that will likely be impractical and not cost effective to license. There's a couple of exceptions to this depending on business process involved, or exporting non parametrized static queries by batch file but real time API integration needs indirect license for all users/devices that consume that data and that's a major constraint when SAP is in the architecture. Same issue for Windows Server CALS except recent IOT SKU version which is OEM only.
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.
Digital Transformation is the key and this is the part which is most neglected. in its true sense, majority of the businesses are missing, once you get this right, the rest of all the pieces will fall down correctly.
If SAP is so dumb and complicated, then why almost all tier1 companies are going after it although the pricing of SAP is high... Management of top companies are not so dumb right
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 need to put an input to receive some sort of output. If you cant give the data to the system, digitally, how do you expect it to return to you what you want? It's not even about SAP, or ERP in general. It's basic mathematics. Did you ever worked with mathematical functions, if you dont define what "f(x)=" is, it does not matter what you gave to x, it's not going to give you the answer that you need. Implementation part of it is very complicated when it has to. If you believe it's easy, try doing it yourself mate. It's one of the most complex job that you can do. And if you cant provide data to system, it will basically not work as well.
That is not an SAP is dumb problem, it is adopting SAP when you business processes are a generation behind problem. Sadly SAP demands the peripheral applications also to be capable. You can't be writing numbers on paper and expect Excel formulas to be dumb because theh don't have the data in them.
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.
SAP is as good as the business process itself. If your processes are redundant and you have inertia to change then despite best practices you will still suck at utilising any ERP for that matter. SAP is as good as the company implementing it and company running it. Don’t shoot the messenger
What u need is much imp in report then we can play with billions of historical data and realtime data. If we can't question chatgpt properly then how we can get proper solution. People are such like if they don't know they call it is dumb. But dumb people don't no.
SAP is dumb because they copy most of the software from Oracle and add certain features to make it look original. Eventually Oracle and SAP are going to become same after 5 or 10 years
When I asked people what SAP stands for I got two answers: Systems Against Production and Submit And Pray.
Lol, that's totally killing me 😂😂
Not Software Against People? :D
😂
from what i've learned in like an hour, SAP isn't for small to medium businesses, but large businesses to communicate between departments. I assume for businesses that trade on the NYSE.
SAP is as good as its user .
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
@@4.0Solutionsit is not that high, just know the cluster, process core, table, fields, and crosswalks/handoffs…you set
Remember computer systems are built from the process of the mind: Cluster=You, Process Core=sections of the brain, Table=left side or right side, Field=body part, and crosswalk/handoff=handshake. Nice to meet everyone. Hope everyone is having a wonderful day.
So if SAP is Dumb, HOW DO you run and manage the information such as MPS and Inventory and Operational performance at scale? Or are we processing a few orders only? SAP is not the only platform but requires defined processes and discipline, which numerous companies lack IMO.
with an ERP solution that's open architecture.
SAP is not actually SAP - in fact, it's one of the most, if not the #1, ERP nowadays! At the end of the day, most people I know that dislikes it is mainly because on how the solution was implemented - not the software as it's. The problem relies mainly on people not committed to the transformational project, bad project management, almost non-existent change management, and so on. The software can cover, via standard + developments, 99% of businesses requirements in the market. For the 1%, there are other solutions that can integrate with it.
EXACTLY!
one big issue I see with integrating internal manufacturing data with SAP ERP is because SAP need indirect licenses for every user or device on the floor, which can be hundreds of users, or thousands of devices. Having a few people at each plant manually interface with SAP via SAP GUI limits it to a few people that can counted and licensed. Integrating the stack from the shop floor, MES, SAP and cloud means an almost uncountable number of indirect data flows that will likely be impractical and not cost effective to license. There's a couple of exceptions to this depending on business process involved, or exporting non parametrized static queries by batch file but real time API integration needs indirect license for all users/devices that consume that data and that's a major constraint when SAP is in the architecture. Same issue for Windows Server CALS except recent IOT SKU version which is OEM only.
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.
Thanks Gaurav. Please also try to bring someone for SAP EWM.
Digital Transformation is the key and this is the part which is most neglected. in its true sense, majority of the businesses are missing, once you get this right, the rest of all the pieces will fall down correctly.
If SAP is so dumb and complicated, then why almost all tier1 companies are going after it although the pricing of SAP is high... Management of top companies are not so dumb right
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.
@@4.0Solutions that's one example, mate
There are rumors that SAP will discontinue it‘s could based IoT offering like Google did.
You need to put an input to receive some sort of output. If you cant give the data to the system, digitally, how do you expect it to return to you what you want? It's not even about SAP, or ERP in general. It's basic mathematics. Did you ever worked with mathematical functions, if you dont define what "f(x)=" is, it does not matter what you gave to x, it's not going to give you the answer that you need.
Implementation part of it is very complicated when it has to. If you believe it's easy, try doing it yourself mate. It's one of the most complex job that you can do. And if you cant provide data to system, it will basically not work as well.
Every ERP needs the right input data from the user. If the user is dumb data result is dumb.
Why not have the edge tell you the data itself? Automate the data entry so there is no room for human input error.
That is not an SAP is dumb problem, it is adopting SAP when you business processes are a generation behind problem. Sadly SAP demands the peripheral applications also to be capable. You can't be writing numbers on paper and expect Excel formulas to be dumb because theh don't have the data in them.
SAP isnt good for small, simple companies -if you are one of them and chose SAP - then u would definitely feel this way
You said that accounting practices are manual, not because accounting people want it like that... then why?
Because you need edge connecvity to process the events
I absolutely despise SAP, it's the biggest pain of my life, thank god for extraktAI, the only thing that makes dealing with SAP bearable
You are saying we cannot do forecast in SAP? I dont think so.
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.
what about SAP BTP
SAP is as good as the business process itself. If your processes are redundant and you have inertia to change then despite best practices you will still suck at utilising any ERP for that matter.
SAP is as good as the company implementing it and company running it. Don’t shoot the messenger
That is not how SAP sells it.
What u need is much imp in report then we can play with billions of historical data and realtime data.
If we can't question chatgpt properly then how we can get proper solution.
People are such like if they don't know they call it is dumb.
But dumb people don't no.
Im sap technical consultant and i can say : SAP is a piece of sh ...😅
SAP is dumb because they copy most of the software from Oracle and add certain features to make it look original. Eventually Oracle and SAP are going to become same after 5 or 10 years