Buying a commerce engine is not a predictor of success. What counts above all is its effective implementation and continued use of the solution in the foreseeable future. But there is no doubt that implementation of a commerce system is a massive challenge for any organisation. Why? Because it complicates processes at many levels. But what is more, it demands changing previous habits and way the team thinks as a whole.
Let’s look at the most common pitfalls made during the implementation of the SAP Hybris system (also known as SAP Commerce Cloud, SAP Commerce, Hybris – these names may be used interchangeably).
Pitfall #1: "We need Java specialists. They will learn Hybris while working on the project."
“An experienced developer will learn everything on the fly if he/she knows Java” (as the leading language which Hybris is based on). This statement should be a red flag for you, especially when the whole team is built on this approach. Consider the following situation. You cannot expect a regular driver to get behind the wheel of an F1 race car and drive without a hitch. They need experience so as not to make a fatal error. It is the same situation with any technology you are dealing with. You need to know and understand its capabilities in order to use it to its full capacity.
Getting to know the platform and how to skilfully implement it is knowledge and experience you and your team need to gain overtime. Not every Senior Java Developer can become a Hybris Expert right away.
When choosing a partner to implement this solution in your company, remember to ask about:
- THE EXPERIENCE OF THE PROPOSED TEAM – check if it is expressed in years and/or completed projects. Certificates are as important as real hands-on project practice. Pay particular attention to the experience of those who will be crucial in the decision making process. They will have the most significant impact on the technological and process aspects of the project and/or contact with the client
- PROPORTIONS – the perfect situation is when a majority of the team has experience in a given technology. Our recommendation in terms of composition is having at least 1/3 of project team members with experience in working with the Hybris platform and could evidence it with completed projects
Pitfall #2: "It’s just a simple frontend change. We are agile. We can handle this."
If we had a nickel for every time we have heard this, we would be millionaires. It frequently occurs that the client thinks a proposed change is a small task and can be done right away. Most often this kind of situation refers to a small modification on the front, e.g. changing the colour or location of a Very Important Button on the page (like the “Buy” button).
Be aware of how such a task looks from the client’s and the project team’s perspective. Let’s assume that it is a simple requirement and the code itself is 15 minutes of work by one developer (who knows where to make it) and that the project team works in Scrum, it means in sprint cycles. Below you will find one of many examples of a list that includes necessary activities.
"SIMPLE FRONTEND CHANGE" – CLIENT’S PERSPECTIVE
1 The need to change the current functionality
2 Informing the team about the need for change
3 UAT (User Acceptance Testing) – optional (best practice)
4 Announcing new functionality implementation to the company
"SIMPLE FRONTEND CHANGE" – PROJECT TEAM’S RESPONSIBILITIES
1 The need to change the current functionality
2 Informing the team about the need for change
3 Deciding if there is room for it in the Sprint
YES: We can do it
NO: You should give up something that is currently being done/planned and will not endanger your Sprint Goal achievement
4 Start of implementation
5 Functional testing
6 Fixes and re-work after testing
7 Re-testing functionality
8 Completion of implementation
9 Setting up a Release Candidate package
10 Uploading the Release Candidate package for pre-production environment for testing
11 UAT (User Acceptance Testing) – optional, if the client cannot perform them for some reason
12 Software regression testing and/or automatic testing, and/or performance testing
13 Package stabilisation and additional testing – optional
14 Preparation of release notes
15 Going live
16 Smoke testing after implementation
17 Announcing new functionality implementation to the company
As you can see, the list of necessary activities is quite long, and people and time are required to fulfil it. These are Sprint resources that are defined, limited and should be used to create increment and achieve Sprint Goals successfully.
Commerce systems implementations are often long-term projects, which are developed in parallel with the support of current production requests (bugs, proposal for new functionalities). How can you act effectively in that case?
OPTION 1. Transfer the maintenance responsibility of some taks to another team, e.g. Application Support
OPTION 2. Separate frontend from backend – More and more popular Headless CMS-based architecture allows you to separate the implementation of the frontend from the backend. Through this approach, there is no need to stop servers in a frontend release and undergo a complicated deployment procedure for the entire application.
In terms of estimation of how much time it will take to implement a given solution and whether the necessary change requires a small amount of work, it is best to trust the partner who carries out your project. An experienced team can value this type of activity, taking into account the specifics of the agile approach to project management.
At ENGINIETY, we often see that faulty thinking about "small changes" is due to the monolithic nature of Hybris architecture. For this reason, we have developed a solution that decomposes the monolith and we offer it to our clients so that they may benefit from it.
Pitfall #3: "Upgradings are time-consuming and expensive, so we don’t do them."
The nature of commerce projects is long-term, so it is inevitable that you will need to upgrade libraries or tools at some point.
TWO GOLDEN RULES FOR UPGRADES:
1 DO YOUR UPGRADES
2 DO IT REGULARLY
Only this way you can be sure that your version of the system is stable and free of currently-known errors, and that you have new functionalities at your team’s disposal.
You wil ask: "Why do I need an upgrade if it works?" In theory, you are right. However, this attitude does not take into consideration important issues such as:
- critical bug
- fixing using new functionalities
- improving stability and speed
- new API to speed up future implementation
These are the elements that bring about the best benefits in the long run, and it is often on such a scale that the profits cover the costs of upgrading the platform.
The cost of such procedures is lower than it may seem at first glance. The calculation should take into account precious resources like money, time and, above all, people. Not only that, the knowledge and competence of the development team are crucial. If it is well structured, then an upgrade should be one of the typical tasks that is planned and performed, as well as the implementation of the new functionality.
Pitfall #4: A out-of-the-box solution vs reinventing the wheel
Here we can see how the wrong approach to this technology and two erroneous assumptions may lead to the downfall of the project:
- „Hybris is a ready-made solution requiring only simple configuration and will work according to my requirements.”
- „We want a new functionality, but we do not know the platform capabilities, so we write everything from scratch.”
You may find that both approaches are unsound. On the one hand, Hybris is a powerful monolith with numerous functionalities. What you need to know is that they rarely fit 100% to the requirements of a given customer. Each company has different needs, processes and guidelines. To implement the functions available within the platform, the box version calls for modification to your unique requirements.
On the other hand, there is a lack of awareness of the broad possibilities offered by the system. The evidence? The number of times we have heard that a given function should be implemented from scratch or, worse, it would be cheaper to write it yourself, starting from the MVP version. On the contrary, practice shows that it is more expensive in the long term, and often the MVP version stays forever (due to the lack of time for its further development).
EXAMPLES OF ISSUES THAT APPLY TO ANY OF THE ABOVE SCENARIOS:
- product promotion system – extensive, you do not have to write it again, it may need to be expanded. Works well enough, it is not worth writing from scratch;
- CMS components for product promotion – Hybris has a large number of different types of components (including product carousels, banners, tiles for advertising). You can use them practically in stride or adapt them to your requirements. That is how you create (with a little help from the development team) a custom solution that no one else has;
- product management – Hybris has a built-in Product Content Management (PCM) tool that facilitates, among others, native integration with SAP ERP or another tool from the SAP portfolio (SAP Platform Integration for two-sided integration with any 3rd party system).
Are there more problems to be aware of?
Sure there are. The complete list of pitfalls is several times longer. Our team’s discussions on this topic suggest that there is a large set of commonly repeated problems. They mainly result from the project team’s lack of experience in the field of best implementation practices and gaps in knowledge of the possibilities or limitations of the implemented Hybris framework.
That is why we emphasise this: the project team must be adequately composed – not only in terms of seniority but also in terms of project experience. At the same time remember that someone in the team should at least partially act as a consultant. It may be one person or a group who advises on what is best for the project, how to effectively use the capabilities of the platform we work with, and what solutions are functional and which to avoid. That is what it is all about: the success of the project as a whole.