Archives July 2020

The seemingly easy to glue together and operate suite of software that is meant to ease the day to day process of an organization, ERP is a lot more difficult to strategize and implement than its functioning lets by.

The engineering of an easy flowing frontend is powered by a much complex backend architecture – something that comes with attached ERP development cost. A cost estimate that is arrived at on the basis of features that are to present in the making of a good ERP system and the market that the system has made for itself.

In this article, we are going to help you understand the different factors that are entailed in the ERP software development cost. But before we move on to that stage, let us first look into the advantages of Enterprise Resource Planning system that have contributed into the positive outlook of it in the industry.

Streamlined Processes

The modern ERP systems are designed to bring all the data together, which ultimately improves the prevalent bottlenecks in the business process, something that single-handedly answers the question – is ERP good for small business?

Better Tracing and Control

If your business deals in digital or physical products, the ERP systems can offer an easy approach to track your products. Here’s how the system make it possible –

Visualizing the Service and Product Movement

One of the primal ERP benefits is seeing how services and products are moving in the pipeline. There are multiple ERP software vendors who offer tools that come with the efficiency of order tracking, revenue tracking, inventory, tracking, and raw material management.

 Advanced Customer Service

One of the reasons why companies invest in custom ERP development is the change that the software brings to their customer service domain offering.

Here are the two ways your customer service domain is made more efficient through the ERP system.

Better Aligned Suppliers and Customers

ERP software is known to improve both backend and frontend relation of business i.e. a relation that the company has with both their vendors and customers. An effect of which is streamlined shipping time and better customer experience.

Support and Evaluation of the ERP System

Once the ERP system is made live in the business, the whole process of evaluation and maintenance starts. This ongoing process looks into and takes care of the system to the T, ensuring that it is performing exactly as it was intended to.

This whole implementation process takes different time according to the different business sizes it is going to be deployed in. Usually, this is what the timeframe looks like 

One of the most discussed software architectures are microservices. In other words, the request to split the monolithic applications of the past into small, autonomous services. However, there are some issues with microservices: They are expensive – as they are required for unlimited scaling – and only work if the underlying culture is embraced in its entirety.

This raises multiple questions. For us in the ERP world, is unlimited scaling a requirement? Also, our applications are expensive enough and a complete shift of the whole application towards a different architecture is often impractical. Nevertheless, SAP has a couple of offerings built on microservices, and we can learn from these examples.

Microservices are autonomous

At its core, the microservice architecture requires each service to be fully autonomous. It has a well-defined network API to get data in and out, no other methods allowed. The decision of which technologies to use to implement the service is up to the responsible team. Sounds simple enough, but the decision has consequences.

A sales order should reference existing customers and material master data, but these are other services and hence not part of our database’s tables. But if they are not part of this database, all features that a database provides for free, including transactions, enforcing foreign key constraints, fast joins and the like, need to be re-implemented on service level.

The obvious solution would be to make the database with its tables one service, and the business logic where sales orders are maintained would be another microservice. Something like a 3-layer service architecture with the UI layer, the application layer and the database layer. The application layer exposes function modules for the various operations and …. Did we just re-invent the R/3 architecture?

Eventing and eventual consistency

The software industry’s answer to that problem is to use events as the information backbone. Every service broadcasts all changes made to the data and the interested parties can listen and persist the required data in their own database.

In the example of the sales order database, it would have tables with material master data and business partner records for reference, except that these extra tables cannot be modified. When the material service broadcasts the event, effectively saying, “There is a new material with the following data”, it is modifying the local reference table.

SAP Cloud Platform’s microservices architecture

Each service deployed is an isolated entity, publishes its APIs in a central registry – the API Hub – and multiple instances can be started to increase throughput.

The CAPM supports even eventing of services but ignores out of the box support of distributing change data across the database instances. SCP does not need that, as the database is used as a service as in a client server model and is not an intrinsic part of the service itself.

One way to look at it is that it combines the worst of both worlds: It scales like a client server architecture and adds the complexities of microservices. Security is maintained outside of the database, services need various bindings, services require defined routes, every service must serialize and deserialize the payload for data exchange, every service needs to reevaluate the user security, etc. In brief, simple things are tedious, complex tasks are extremely difficult.

SAP Data Quality microservices

Another example are the SAP EIM Data Quality services to validate and cleanse various aspects of address data.

For such an offering, a microservice architecture is perfect. The required address reference data is part of each service instance. There is no need to sync the data across instances due to the static of the postal data. The user sends a http request with an in-doubt address payload to the service and gets back the corrected address, the information on what has been corrected, and the confidence level. It scales perfectly and the overhead is little.

It has emerged recently that SAP has extended its end-of-support date for legacy goods, moving from 2025 to 2027 – including a three-year transitional duration and a 2030 final cut-off stage. Up to then, customers who are not on S/4 Hana will be moved to a “customer-specific maintenance model”-translated: your service will become even more expensive.

In the run-up to their deadline(s), SAP have waged a long marketing war in order to move their customers to S/4 Hana; not just the use of deadlines as an ultimatum, but also releasing positive survey results and customer numbers, to encourage any who are undecided.

However, Support Revolution is sceptical of SAP’s methods, because their results and statistics aren’t consistent with what we’re seeing in the wider ERP market.

The study states, “The 300 participants […] spanned 10 countries covering three regions, from organizations with 1,000-25,000 employees across a multitude of industries and were either planning to deploy (73%), have in production (9%) or currently deploying (18%) SAP S/4HANA.”

The survey results suggested that, of 300 participants, 100 percent of them were either deploying S/4 Hana in the near future, or were already doing it. It is also worth noting at this point that this survey was funded by, and samples were provided by, SAP.

As you might expect, the figures SAP have given here seem a little far-fetched, compared to what other surveys and reports have found and the general opinion of S/4 Hana at the moment.

Why are customers worried about S/4 Hana?

We’ve established that SAP’s marketing strategies are inconsistent; namely, their customer surveys don’t actually line up with their customers’ feedback.

But why are SAP’s customers hesitant in moving onto the newest product? What’s holding them back – and what should you, and your organisation, bear in mind before making your minds up?

SAP’s customers don’t want to play

Customers have understandably been cautious about moving onto S/4 Hana. Any organisations moving to the cloud-based, SaaS S/4 Hana would not see a typical ‘lift-and-shift’ upgrade – rather a full system reimplementation. Almost like installing a brand-new ERP system.

Therefore, any customisations that customers have developed on their systems become very difficult to shift onto the new cloud platform. The options of customers who want to stay with SAP generally come down to these three choices:

1. Deny the S/4 Hana upgrade, and, in 2030, be put onto the maintenance model;
2. Accept the upgrade, and make every effort to rework the new S/4 Hana software to suit their needs (an expensive and in some cases impossible option);
3. Accept the upgrade, and change working processes to suit the new S/4 Hana functionality.

The support revolution of SAP

This leaves a lot of customers not going anywhere, not receiving any innovation or added benefit from their existing ERP suite, and yet, they are still expected to pay SAP’s substantial support fees.

High prices, for a service of very limited return. In any other situation – gym membership, insurance, streaming services – you’d consider cancelling your contract and looking elsewhere. Which hasn’t really been an option for Oracle and SAP customers – until fairly recently.

SAP’s management has been the source of distrust and dissatisfaction. The employees are now expected to answer for the low levels of customer satisfaction. SAP is becoming a grassroots democracy.

It wasn’t just the former deadline 2025 that had many customers dissatisfied with SAP’s management. In the past few years, executives also seemed to completely ignore on prem. Cloud was supposedly the way to go, but many customers had reasonable doubts.

SAP promises it has seen reason. During FKOM (Field Kick-off Meeting) 2020, it proudly proclaimed: We are ERP! There were no over-the-top praises of Hana. The once ambitious cloud program Embrace has effectively been reduced to an exclusive contract with Microsoft. AWS as Embrace partner is practically invisible. Google is still trying – most recently with a booth at the 2020 DSAG Technology Days – but customer interest is low.

SAP’s management failed to recognize the sign of the times. As a result, customer satisfaction is at an all time low, indicated by e.g. its negative Net Promoter Score (meaning that for the first time, customers would not recommend SAP’s software).

One step forward, three steps back

Another ambivalent example of how SAP is listening to customers again: the new deadline 2027/2030. To extend maintenance for Business Suite 7 with AnyDB as well as AS Abap, AS Java and the NetWeaver stack was the right decision – but who is going to pay for that? Technical, organizational, personnel and licensing challenges lie ahead. One swallow doesn’t make a summer, and extended maintenance doesn’t solve all of customers’ problems. Customer dissatisfaction roots in so many things: inconsistent on-prem and cloud APIs, confusing business partner definitions, half-baked roadmaps as well as lack of integration.

Another construction site: SAP Lumira

The ERP company seems a little misguided in general. Of course it’s the right decision to offer customers a strategy for visualizing analyses and big data – Lumira enjoys high customer acceptance, after all. However, it’s the wrong decision to cancel Lumira without a clear migration path to SAP Analytics Cloud.

Asking customers for their opinion is the right thing to do but asking customers what to do is another thing entirely. SAP needs to realize how big a role it plays in customers’ digital transformation. SAP is the ERP company, and customers look to it for answers and solutions, not just products.

SAP is taking a carrot-and-stick approach to moving customers from its legacy ERP software, Business Suite 7, to its newer S/4HANA platform.

The carrot is a bold promise to support S/4HANA at least through 2040, meaning that businesses switching today will get over two decades’ use out of the new platform.

SAP co-CEO Christian Klein says enterprises are keen to move to S/4HANA, but some of the larger ones are telling him they won’t be ready by 2025, the deadline SAP had previously set to end support for its legacy software. For those companies, “It’s not so much about the technology, it’s really about adapting long-standing business processes, adapting to the needs of the customers in the digital world,” Klein says.

There’s also been some concern that an SAP skills shortage could leave some customers without the help they need to migrate their systems.

The 2 percent solution

Extended maintenance will cost an additional 2 percent of the annual license fee, on top of the 20 percent fee for mainstream maintenance.

The new cut-off date will affect users of SAP’s core enterprise software component, ERP 6.0, and the core applications of SAP Business Suite 7, including Customer Relationship Management, Supply Chain Management and Supplier Relationship Management.

Procrastinators hoping that SAP will relent and offer another extension in future are out of luck: “For extended maintenance for the Business Suite 7 core applications, the end of 2030 is really the final date,” Klein says.

Even 2027 will be too soon for some, says EAC’s Greenbaum, noting that there are companies still running instances of R/2, a version of SAP’s ERP system that was superseded in the early 1990s.

The extension will remove a key commercial argument for SAP competitors such as Oracle, who have been playing on the uncertainty of what will happen after 2025 to tempt customers to switch, says Greenbaum.

t’s not a sign that CIOs should relax, he says. “I don’t think the customer of any vendor in this industry should be putting their feet up on the table and relaxing about digital transformation and about upgrading their business processes,” Greenbaum says. “But on the other hand, this allows for a calmer and more measured strategy, and that’s what people want.”

Many big data projects I have been asked to review were in critical condition and the root cause always was that the team followed the rulebook on how to build a data lake to the letter.

One of these big data rules is to transform the data at query time instead of preparing the key performance indicators (KPI) upfront and allow only those to be analyzed.

All too often the rule is executed by dumping all data as-is into the data lake. CSV files, database exports, spreadsheets, text documents,… it is chaos. As a result the data is physically present but essentially inaccessible.

Late binding

A data warehouse is supposed to be the single point of truth. Everybody can query the “Revenue” and everybody has the same definition of what “Revenue” contains and what it doesn’t. While this is a good idea for many measures, the definition of others is not always as clear.

In the weblog analysis the KPI “reading duration” is defined as “time between accessing one page and within 10 minutes another”. Why 10 minutes? What would be the impact on the calculated duration if using 9 minutes instead? While it is definitely a good idea to provide a KPI with the official definition “reading duration” for correlations, the data scientist will want to do more.

Hence the requirement to make the raw data (and consequently big data) accessible. But does that also mean in the original source format, meaning a 1:1 copy of the webserver logs? What will happen if that data gets converted from the text format into a compressed binary format easier to read? Would that violate one of the data lake rules if 100 percent of the information is present but in a different format?

New deal

Because storing the data in databases was the only option in the past, many data sources could not be added to the data warehouse or only in a pre-aggregated fashion. Today, I would use the data lake as data warehouse staging area on steroids.

All data are added in a binary compressed columnar table format. Parquet format* is the defacto standard. This makes it easier for the data scientist as well as the data warehouse to consume the data. The data warehouse still contains the aggregated data, using the official definition of the KPI.

Data science

The reason the data warehouse plays a significant role in this context is because of its ease of use and speed. Most of the users only care about the predefined KPIs. Their typical analysis is to create correlations between the data. And that is the sweet spot for databases like SAP Hana – smaller volumes, fast aggregations, fast search, many joins.

A data lake is the exact opposite. It can store unlimited amounts of data cheaply, can parallelize processing on a single table efficiently and provides complex processing way beyond SQL queries.

The combination of the two, data lake and data warehouse, is the winning proposition.

In this SAP MM blog article, you will find different aspects of the SAP MM Module, such as its functionalities and operations, as well as different components and subcomponents including master data, purchasing, billing, human resource management, and inventory management.

In this SAP MM blog article, I will cover these topics which are given below :

• What is SAP MM Module?
• Features of SAP MM Module
• Advantages of SAP MM Module
• Procurement Process
• Types of Procurement
• Basic Procurement
• Special Procurement
• Structure of an Organization
• SAP R/3
• Procurement Cycle
• Inventory Management

We will begin this SAP MM blog article by learning the SAP MM Module. SAP MM Module is an integral part of the SAP ERP Software. SAP Material Management is used by various companies to handle their purchasing and transactional data as it is both cost and time-efficient. SAP Material Management belongs to the logistic function which helps the industry from procurement to delivery of products. SAP MM Module consists of various units to handle material procurement and vendors, inspect the material condition and quality, as well as payment of the vendors. What is SAP Business Process in SAP MM Module? SAP Business Process is an integral part of the SAP MM Module. It handles the sales, Manufacturing, Distribution, Unit Maintenance, Planning, and Warehouse Management of a company. It helps manage the Inventory and Human Resources of a company.

Features of SAP MM Module

Some of the key features of SAP MM Module are as follows: It deals with Inventory Management and Material Management. It is a process that keeps in check the scarcity or violation in the Supply Chain of a company. It Manages Procurement activities. To accelerate productivity and cut the cost, it manages Material (products/services) and resources of a company. It handles Master Data, Valuation of Material, Material Requirement, Invoice Verification, etc.

Advantages of SAP MM Module

• It minimizes the cost of operations.
• It reduces inventory losses by removing unnecessary or obsolete material.

Procurement Process In SAP MM Module

This article will certainly help you to understand about the Procurement Process in an SAP MM module. This SAP MM blog article will show the various kinds of Procurement Process.

Every company requires material or service to satisfy their requirements, and thus, they purchase them. This procedure is referred to as procurement.

In order to better meet the needs of our customers we are constantly evolving and innovating our products.  Topics related to data integration and data orchestration are evolving at an especially rapid rate as companies need to apply data management strategies not only to their SAP data, but also to their 3^rd party data such as streaming data, data from various cloud solutions, IoT, media and other types of data which is required for business processing and data-driven innovation.

SAP Data Hub is a data orchestration and management solution running on Kubernetes, leveraging open source and embedding machine learning capabilities. It was released by SAP in 2017 to deal with big data and complex data orchestration working across distributed landscapes and processing engines, enhancing developer productivity and extracting value from distributed data.

During the last two year’s we’ve seen a lot of customer projects and landscapes evolving towards automated and intelligent data integration embracing machine learning processes.

In 2019 SAP Data Hub was released as managed service on SAP Cloud Platform with the name SAP Data Intelligence.  The name SAP Data Intelligence highlights the evolution of SAP Data Hub to operationalize data science and machine learning with the inclusion of the SAP Leonardo Machine Learning Foundation. SAP Data Intelligence provides all the integration, orchestration, metadata management, connectivity and rich services of SAP Data Hub with the services of SAP Leonardo Machine Learning in the cloud.  This combination is critical to enable collaboration between IT and data science teams. Data scientists continue to work with the tools they love, while working in collaboration with IT from prototyping to production, ensuring AI and machine learning projects can scale and are managed within IT guidelines. At the same time, the development and operation experience for data integration and ML is streamlined.

Digitalization poses new challenges. To avoid pitfalls, companies need a structured approach. This is also true for S/4 Hana implementations as digital core, and a business transformation roadmap is indispensable for any migration.

Companies are currently dealing with one of the biggest challenges of the digital age: digitalizing all their business processes. Furthermore, they have to start leveraging new technologies like artificial intelligence, machine learning, predictive analytics or robotic process automation. Without them, the implementation of new, digital business models becomes impossible.

With S/4 Hana, SAP offers customers a stable core which, combined with SAP Cloud Platform, improves agility as well. This guarantees seamless integration and the possibility to leverage new technologies, resulting in a number of benefits, e.g. reduced maintenance or upgrade efforts.

Transformation roadmap indispensable

After these evaluations, an SAP business transformation roadmap becomes indispensable. It serves as a guide on how to best align business requirements with technological possibilities.

Competent and knowledgeable consultants or partners are able to assist in this process. They can make estimates about the costs of S/4 transformations, which is a problem that 46 percent of respondents weren’t able to tackle on their own. Additionally, partners offer know-how and experience that 32 of respondents were lacking.

Digital innovation at the forefront

Future-proofing processes means to evaluate how new technologies like artificial intelligence, machine learning, blockchain, the Internet of Things, predictive analytics or robotic process automation can benefit companies. During these evaluations, it’ll quickly become clear that all of these innovations only really make a difference when companies combine them in a way that aligns with business strategy and long-term goals.

With SAP Cloud Platform, SAP offers a solution that combines these intelligent technologies and offers necessary integration services. SCP’s Accelerator packages are specifically designed for different industries and core functionalities and accelerate the implementation of digital innovations.

Roadmaps have to be accompanied by creating, testing and eventually implementing prototypes. By implementing prototypes, digital transformation becomes visible, which makes it easier to convince even the most hardcore sceptics of the importance of digitalization.

The name SAP Data Services is used for an entire family of products. The core is SAP Data Services itself, then there is SAP Data Integrator, SAP Data Quality and SAP CPI-DS.

The first three are the same product but differ from the enabled transformations. Data Integrator has all the base transforms plus typical data integration transforms like History Preserving. The Data Quality bundle consists of the base transforms plus Data Quality transforms like address cleansing. The SAP Data Services bundle contains all transforms.

Over the years Data Services grew to a very powerful tool and allows to implement every requirement efficiently and quickly. When I was part of the team, the development guideline had been to enable the customer performing even the most complex transformations with the combination of a few transforms. The tool also supports all SAP APIs available to pick the best suited one. Connecting to the database, generating Abap code for the extraction, call BAPIs/RFCs, send and receive IDOCs, use the modern ODP/ODQ API, web services, restful,… you name it.

Simplify integration

At one point in time, our team got tasked with a cloud version of an ETL tool – Cloud Platform Integration – Data Services or short CPI-DS. Its backend is still a normal Data Services but easier to install. Building a proper Web UI is expensive and, in some areas, not even possible.

Also, the goal was to simplify things. The easiest way to simplify a UI and keep development cost down is to remove functionality. CPI-DS can therefore be used for some specialized cases only.

SAP Data Services delivers on promises

All the marketing statements I heard recently have been supported by Data Services since the beginning. “Move the transformation to the data, not the data to the transformation” (SAP Data Hub) is called a pushdown in Data Services. “ELT instead of ETL” (SAP Hana) means to extract (E) the data first, then load (L) it into the target system and do the transformation (T) inside the database as follow up step.

Depending on the case, this is a good idea and therefore Data Services supports both approaches and the optimizer picks what makes the most sense.

Realtime Data Integration is supported also, but not implemented very well. It starts with the question “What data has been changed?” – a requirement for realtime streaming of changes. The philosophy of Data Services is to provide all techniques and APIs for any given source system and the user can choose which one to use. This makes sense as each has pros and cons.

There are other tools, SAP SLT for example, which can do a single method only, which reconfigure the source system to produce the changes and therefore getting changes in realtime is simpler. Both approaches have their merits.

The focus of Data Services on batch performance has downsides on transactional consistency, stability of dataflows running for multiple days as it would be required in realtime.