5 items to streamline your e-commerce changes

24 Aug 5 items to streamline your e-commerce changes

For those who do not know or have never worked in an e-commerce operating environment, know that everything works on the brink of chaos. Some retailers keep a large dashboard visible to everyone with daily and monthly business goals, and depending on the color of the numbers (green or red), chaos begins to unfold. It looks like a battle scenario with arguments crossed and tangled up with others, all talking at the same time but one wanting to speak louder than the other. The fact is that decisions are taken at any time and the entire operational chain needs to be prepared for the change to reach the customer. Actions from different sectors are carried out at the same time and, together, they manage to bring alternatives to the consumer so that the expected result is generated. Trust me, it’s common for this to happen in an environment that involves a highly competitive business, and I’m not saying this is necessarily bad, but it doesn’t have to be chaotic either.

With geographic coverage often national and with no time to close the doors, agility is the soul of business in an e-Commerce. Therefore, I list 5 items that I think are fundamental for all this to work:

1. Teams beyond departments and with a sense of ownership

In some places I’ve worked, to generate a campaign you had to bring people from all sectors together several times – it took weeks or months for decisions to be made. People who sometimes did not even have the autonomy to make decisions about what type or authority would be given to the solution ended up participating in the decision, which meant much more time to implement or execute these decisions.

As in any type of company, having capable and well-trained people generates efficiency in the engine and more expressive results. But people with the same profile will add efficiencies within a department, not necessarily in an end-to-end solution. Therefore, it is important to build a team with people with different profiles, multidisciplinary, so that a solution is complete and agile.

Within a technology team, I see the following profiles:

• Designer / UX: will generate the best graphic communication to the target audience;
• DevOps: will ensure the infrastructure will support the new campaign;
• Front-End Developer: will implement the communication solution and integrate with the back-end, where the business rules are found;
• Back-End Developer: will implement the business rules on the platform, if it does not already exist;
• Tester / QA: will guarantee the quality of the created solution;
• Scrum Master: will guide or guarantee the good agile practices adopted by the team;
• Product Owner: will indicate the most important items to the team through the backlog and will plan the budget used in the solution.

However, I think the team should not be composed only of technology profiles. The technology team will not be able to get started without the business being explored or analyzed. For that, I would add a few more profiles:

• Commercial Analyst: will bring pricing and margin information;
• Digital Marketing Analyst: will verify accesses and plan the publication of the solution in digital media;

Some auxiliary profiles can be used depending on the solution, such as logistics and after-sales analyst, for example.

With these profiles, I consider that the team is complete for any type of action or solution to be used on your website/product. Remembering that these profiles can be in a structure with a unique sense of ownership – such as a team of digital channels or e-commerce.

2. Instrumentation and not just BI

Gathering information about sales, conversion, audience, and other business factors is critical. The Digital Marketing Analyst is fully able to verify all this with analytics or BI tools. Decisions are usually initiated or based on business data collected over a period of time, and there is hardly any query for data on technology resources to know the impact of a new solution or campaign.

It is not usual to make decisions with the involvement of people responsible for the infrastructure of the solution, on the contrary, DevOps usually only know about the change after they notice a strange behavior in accessing the servers. I saw many campaigns or movements fall to the ground because the entire infrastructure was not planned or sized correctly. An example of this was the last Black Friday of 2014, when several stores could not support the volume of accesses and all sales were compromised. When the solution was given, half of the campaign time had passed and many sales had been lost to the competition.

Even with the auto scaling feature in the cloud, there is a configuration with a maximum limit of resources used and, if the campaign is expected to use more resources than this maximum, the auto scaling will not be of any use, as the entire infrastructure will not support the volume of accesses generated.

3. Agile methods and best practices

The adoption of agile methods is a reality that has been shown to be efficient in the delivery of any digital product. Getting your operation to apply some concepts will greatly increase agility.

As an example I take a recent case in which there was a need to change the integration of an e-Commerce platform with a new ERP. In May of that year, we had a first conversation about the requirements, but the ERP technicians had not been involved, only the managers were present. Three months passed (yes, three months!) until a meeting with the technical responsibles was held. Within an hour, everything was resolved. The practice of forming a team and everyone sitting together to solve a problem is one of the main benefits of agile methods.

Some other practices bring several great benefits that speed up the delivery of a digital product. I highlight the definition of ready (DoD – Definition of Done) and the daily meeting (Daily Meeting) of the team. The first one gives clarity to whoever is going to develop about the rules and acceptance criteria so that it can go into production – who hasn’t spent weeks or months validating a development? With a well done definition of ready, this validation time drops a lot. The second, daily meeting, usually increases the team’s productivity by the simple fact of drastically reducing idleness due to lack of definition or understanding; in addition, it generates efficient communication and gives transparency to those involved.

4. Modern and uncoupled platform

Choosing a platform is not a simple job. Generally, it is chosen based on market adhesion, budget and a set of features matched to business requirements. Rare were the times I witnessed a choice for ease and delivery of customizations, architecture or technology.

If your operation has any differential in relation to the competition in the market, your platform will require customizations that will be present from the first day of its implementation. If the platform is not prepared to facilitate the work of the development team, the product is bound to die in the short term, even if it is put into operation. The time required by the business for changes will always be less than the time offered by the technical staff, and the friction generated by this inconsistency will lead to a final agreement that will be the exchange of the platform.

Finding a SaaS platform can be a way out if your business is not focused on digital retailing and doesn’t need constant change. The commercial negotiation involved with SaaS companies often transforms a partnership bond into an equity bond, as most are negotiated by a factor on revenue. You will definitely have a lot less worry about your operation, but you will also have a lot less autonomy to generate and implement changes. That’s why I don’t recommend the SaaS solution if you want to adopt an agile culture to your business.

Trying to find a modern platform in the market, with technology and architecture conducive to agility in delivering customizations and in the way expected is challenging; usually some are found with favorable technologies, but with complex architecture. Therefore, large retailers bet and invest in their own platforms, defining their architecture that generally falls under a pattern of decoupling between the presentation layer (front-end) and the business layer (back-end). This architecture allows the evolution of multiple channels or ends of your business at the same time. But this is only possible because in this architecture you will have one and only one solution with services (API) common to your business. This architecture could lead us to a future in which we’ll talk a lot about u-Commerce (Ubiquitous Commerce – theme for another post).

5. Engineering for continuous delivery

Once a change has been implemented and the entire validation process has been done, it needs to be deployed, that is, it needs to be released to the production environment. The implementation process, for those who know it, always involves a very high risk to the business as it can stop the operation of your e-Commerce.

The main deployment strategy is to clone the production environment as a standby environment to apply the change and then do final testing and then switch between environments. Theoretically simple, but there is a very complicated part to this story. The tricky part is deploying the new version of the platform knowing what files need to be updated, what settings need to be done, what scripts need to be run, and that everything is applied in the right sequence. I don’t see an infrastructure or production team being able to do this without having extensive documentation in every detail; and that’s where the deployment process often fails – writing a cake recipe with all the smallest details is very difficult and even harder is getting one person to do all the steps correctly. That’s why I consider it extremely important that this process has a level of automation that facilitates or speeds up the creation of a parallel environment, update platform files, update environment variables when necessary, run update scripts in the database and rollback when something in this process fails.

As an example, we set up a deployment automation on an e-Commerce client using some services and tools from a Cloud Computing partner and the feedback was extremely satisfactory. Our concern with deployment was almost zero, we were only monitoring the process in case something really bad happens (and it hasn’t happened until now). But what creates the most value in all of this is that our client is extremely relaxed and confident when we plan a new deployment.

About these 5 items, what do you think? Do you agree, disagree? Leave your comment and we’ll explore this subject together, as it’s really a very broad subject.