30.04.2018 / Volodymyr Rubych

I started my work on e-commerce development field more than 10 years ago from a topic of my graduation project in university. My choice was to develop a B2C store on the then-so-popular (in 2006) OsCommerce open source platform. The scope included a PIM for the OsCommerce engine, a few payment methods, shipping modules, etc.

I did an easy one, without various difficult integrations, without thinking about such important things as scalability, system performance or maintainability. Let’s say that system was monolithic, non-modular, difficult for any modifications, even from UI perspective, slow and inefficient. But the right choice was that I decided to do it using an existing open source platform.

After that, I used to work with a lot of different e-commerce platforms: wooCommerce, shopify, WP eCommerce, zencart, Magento, OpenCart, and I have practical knowledge and experience to compare them and recognize the evolution of each.

From those days, technologies have changed a lot. There’s a vast variety of new powerful e-commerce platforms available today, but only few of them are on the enterprise level and could be applied as enterprise for a large-scale businesses.

The leading companies who provide enterprise e-commerce solutions are SAP Hybris, Magento, Oracle and IBM. By chance, during the last 3 years I’ve been working on SAP Hybris projects and I can affirm that the evolution of this platform and the whole e-commerce direction is really impressive.

Moreover, based on OVUM predictions, in the nearest future the retail trends will be changing even more rapidly, so e-commerce platforms should be able to react to these changes appropriately. That’s why all of the providers/vendors are trying to move technologies and sell platforms like SAAS Cloud, which makes applications more flexible and independent with microservices, integrate AI and machine learning, etc.

It is absolutely natural that each business is unique from the perspective of business processes, workflows, company internal rules and regulations. That’s why platform providers/vendors should also maximize flexibility and make business processes configurable in their solutions out of the box.

The most difficult question for a company which has decided to create an enterprise online store is choosing whether to use an existing platform or develop their own solution from scratch. Enterprise platform is not cheap, but implementation of a custom solution can be even more expensive and, just as importantly, very time consuming.


First of all, the company should do some research and identify levels of risk, the main goal of the future solution, scale, scope, schedule, technologies and budget. Besides that, the goal of the future system should be predefined from the very beginning for choosing best applicable application architecture and approach in general. The goal may change or the target may become clearer during the implementation phase. As a result, it will affect solution and processes, but not the fundamental things agreed on preliminary analysis, system analysis and design phases.

If we are not limited in time and budget, implementation of an own solution is the best and the only right choice. The result is that finally, we will have a 100% match for our business needs. Is it possible in real life? Unfortunately, this is very rarely the case…


Nowadays, e-commerce systems are very complex and multilayered from a technical point of view. By layers, I mean such system components as CMS, ERP, CRM, and the search engine, which should be integrated into one system and cooperate with each other.

Each layer may differentiate by their own implementation and technological stack. For example, CMS part written on Java or PHP, interacts with Oracle or MySQL database, with implementation of search through SOLR. Finally, this part of e-com CMS is integrated with some third party PIM, with SAP CRM and ERP. Technologically, to maintain such a system, a company should have an expert in each layer. Let’s talk about it later.

If we choose to use an enterprise platform, in most cases we are safe with new features, future updates, required level of performance, security and quality. Instead of implementation of specific features, we can use already existing modules, plugins, or extensions. API of those systems is very flexible and easily modified and reused. Such platforms as Hybris are well documented, and professional communities and forums with required information are widely available.

An additional benefit of platform use is that all of the layers are implemented on the same technological stack, all modules inside each layer are written in the same programming language, and stable and compatible frameworks are in use. So we are avoiding a mix of technologies and approaches on the project, which are incompatible with each other and potentially may cause big issues in future.


System integration – The process of creating a complex information system that may include designing or building a customized architecture or application, integrating it with new or existing hardware, packaged and custom software, and communications. Most enterprises rely on an external contractor for program management of most or all phases of system development. This external vendor generally also assumes a high degree of the project’s risks.

To allow systems to be integrated easily, the development of the system API should be planned from the very beginning. As we can see from the definition above, this is the most risky, difficult and unpredictable part of each enterprise system. Most of the platforms provide their API’s for integrations and default integration mechanisms. It reduces the potential level of risk somewhat, but still this is the most difficult phase of enterprise system development.


The implementation of a custom solution requires mature, high-skilled people who are experienced in similar kinds of development. Finding the right person who will work efficiently as a team player can be very challenging. At this stage, any lack of coordination and organizational skills will slow down the development. Furthermore, the cost of disorganization and inability to work together can be very high. Thus, meeting a tight deadline is impossible. Please note, that I haven’t even mentioned any application design mistakes people may do unintentionally, which happen very often in enterprise system development.

For a platform customization, we need mature and qualified people as well, because developers have a lot of possibilities to implement the same functionalities and features in different ways in platforms like Hybris. But they need to choose the most appropriate one, which will fit the current solution and comply with requirements.


Time is something very difficult to estimate and it’s very important to do this estimation properly. For each enterprise solution, the scope may vary rapidly, and change requests happen very often. Adaptability for market changes plays a key role in business, and it is very important to be on time and faster than your competitors.

So, developing your own solution may be too risky to choose and extremely time consuming. When using a platform, go-live with basic functionality and a team of 7 people is possible in 3 months. By basic functionality, I mean product catalog, product variants, simple promotions and order placement.


If time is difficult to estimate, the case with budget estimation is even more difficult, because budget depends on development time and time is an unknown variable. And just imagine the time we need to design and test an enterprise e-commerce system! Collecting requirements, analysis and design, and testing may overrun the budget for the full project.

For a platform, we just need to customize it for the company business processes. That’s why calculation of the budget is much easier in this case. We need to take into account the license cost and estimate the development efforts for platform customization due to customer needs.


Let’s imagine that we are done with our own B2C system development, and after looking at the positive and increasing statistics of e-commerce sales, our company has decided to take the next step and extend the system for a few more countries. This is something we should probably do from the very beginning of the project, but in practice, we would need to start development of a new system, because the scope of changes will be equal to the whole previous development.

Furthermore, the count of end users of the system is very underestimated and it affects the general system performance in the near future. Is it possible to modify existing application architecture for increasing system performance later on? Yes, but the scope of changes is huge.

What about testing and continuous delivery? Testing is my favorite topic 🙂 And as we previously discussed, most projects are multilayered, and connect a big amount of integrations with third-party systems and existing legacy systems.

In the case of our own custom solution, we should do unit testing for each separate module, integration testing for validation of modules integration inside of each layer, system testing of each layer, and finally regression testing of subsystems cooperation and the system behaviour as a whole. Lack of testing may cause financial loss and loss of company reputation. So the company needs to do testing as quickly as possible and satisfy the required level of solution quality, or do not change anything.

Rapid market changes require on-time and direct actions, that’s why changes and modifications of e-commerce solutions quite often are the real-life case. As a result, we need to apply regression testing for all the stages mentioned above.

The main benefit from using a platform from the QA perspective is that we do not need a testing platform itself. We need to test only specific changes/modifications done by us to be sure the whole system works properly. That gives us better dynamics, stability and possibilities for quick changes and continuous delivery.


Maintaining a system or any system layers is not an issue if we are a product company and we have all the required skillset on board. But what to do if we are a company which developed a system with external resources and switched from the development stage to maintenance?

From the business point of view, it is expensive and inefficient to utilize the whole team in the maintenance stage. Companies are trying to minimize maintenance costs by using only a few persons, or even switching to a third-party company. It will also require a wider set of skills and people to maintain the system if it was developed from scratch with different technologies.

With platform usage, it is much easier to maintain the system because the company just needs a person who has the experience in development or maintaining the specific platform.

As a conclusion, only a few companies in the world have succeeded with their own implementations, I mean such companies as Amazon and Rakuten. If a company needs to go to market fast with the lowest level of risk, I’d recommend to select a strategy of development using an e-commerce platform.

Some statistics regarding leaders in e-commerce platform development can be found by the following links:

2017 Gartner Magic Quadrant for Digital Commerce report

The Forrester Wave™: B2C commerce suites, Q1 2017 report

The Forrester Wave™: B2B commerce suites, Q1 2017 report

The Forrester Wave™: B2B commerce suites for midsize organizations, Q3 2017


If you are interested in e-commerce development, contact us for more details (Mariusz Papiernik tel. +48 690 540 522 or Volodymyr Rubych tel. +48 733 936 306)

30.08.2016 / Jenna Ruostela

Verkossa yritykset kohtaavat suuren massan asiakkaita päivittäin. Jokainen verkkokaupan asiakas jättää jälkeensä paljon dataa: tuoteklikkauksia, hakusanoja, ostoskoriin lisäyksiä, markkinointibannereiden avaamisia, toivelistoja, hylättyjä ostoskoreja, selain- ja laiteinformaatiota ja parhaassa tapauksessa myös tilausrivejä. Tilauksen jälkeen saattaa myös syntyä hyödynnettävää aineistoa: tuotearvosteluja, some-jakoja, tuotepalautuksia, reklamaatioita tai yhteydenottoja asiakaspalveluun. Miten tämä eri lähteistä kumpuava data saadaan valjastettua yrityksen liiketoiminnan hyödyksi? Miten asiakaskohtaamisia voidaan parantaa datan avulla? Ja keitä tämä yrityksissä koskettaa?

Monissa yrityksissä Harvard Business Review -raportin mukaan dataa kyllä kerätään, mutta jalostuuko se lopulta informaatioksi, tietämykseksi ja konkreettisiksi toimenpiteiksi asiakaskohtaamisissa ja liiketoiminnan ohjauksessa? Viisaudeksi, jota koko yritys voi hyödyntää? Alla esimerkkejä siitä, miten eri tahot yrityksessä voivat hyötyä asiakasanalytiikan antamasta ymmärryksestä.

Ylin johto: ”Miten meillä menee?”

Yrityksen johtoa kiinnostaa yleensä avainmittarit, jotka kertovat liiketoiminnan tilasta ja kehityssuunnasta: digitaalisten kanavien osuus kokonaismyynnistä, asiakaskannan ja tuote-/asiakaskannattavuuden kehitys, parhaiten ja huonoiten menestyvät tuoteryhmät, voimakkaimmin kasvavat ja kutistuvat asiakassegmentit, muutokset tilaustrendeissä, mahdollisesti epäonnistuneet asiakaslupaukset ja reklamaatiot sekä poikkeamat asiakkaiden kannattavuudessa.

Näiden perusteella voidaan tehdä erilaisia johtopäätöksiä: Vastaako verkkokaupan kehitys sille asetettuja tavoitteita? Pitääkö uusasiakashankintaan panostaa? Pitääkö tuotteiden ristiinmyynnin, hinnoittelun tai tilauskokojen optimoinnin eteen tehdä toimenpiteitä? Ja kun tilauskanta on kasvussa: kestävätkö varastot ja logistiikka?

Eri lähteistä kerätty, yhdistetty ja selkeästi visualisoitu data auttaa johtoa pysymään jatkuvasti kartalla.

Markkinointijohto: ”Mitkä aktiviteetit ovat kannattavimpia?”

Rakettipoika ja analyyttinen asiakaskohtaaminen Markkinoinnin ja kampanjoiden primääritehtävä on tuottaa yritykselle lisää tunnettavuutta, kiinnostuneisuutta, liidejä – ja lopuksi uutta kassavirtaa. Mutta miten tiedetään, valuvatko markkinointiin käytetyt eurot hukkaan? Mitkä markkinointiin kuluneet eurot löytävät tiensä takaisin yrityksen kassaan korkojen kera?

Avaako kukaan sähköpostiin lähetettyjä uutiskirjeitä? Johtaako tämä kävijämäärien kasvuun verkkokaupassa? Klikkaako kukaan auki vaivalla tehtyjä kampanjasivuja? Herättävätkö tuotenostot asiakkaat konkreettisiin toimenpiteisiin, ostoskorilisäyksiin ja uusiin asiakassuhteisiin ja tilauksiin? Johtaako kampanjahinnoittelu tilausvolyymin kasvuun?

Verkkokauppias (“eCommerce manager”): ”Miten kehittää verkkokaupastamme entistäkin kannattavampi?”

Käytettävyys, helppous, nopeus, oikea tuoteportfolio, sopivat lisäpalvelut, toimitusvarmuus… Jotta verkkokauppias onnistuu näiden luotsaamisessa, tarvitaan jälleen kerran datasta jalostettua ymmärrystä.

Suorittavatko asiakkaat verkkokaupassa jatkuvasti hakuja, joilla ei lyödy yhtään tuotteita? Puuttuuko verkkokaupasta tuotteita, joista asiakkaat ovat jatkuvasti kiinnostuneita? Joutuuko asiakas aina rullaamaan hakutuloksien viimeiseen tuotteeseen, jotta löytää etsimänsä? Pitäisikö hakua ja hakutulosten järjestystä optimoida? Hylkäävätkö asiakkaat paljon ostoskoreja? Pitäisikö checkout-prosessia suoraviivaistaa, vai mistä kiikastaa? Saako asiakas tuotteensa ajallaan vai ovatko toimitukset jatkuvasti myöhässä? Kestääkö logistinen kone?

CIO: ”Miten allokoidaan IT:n käytössä olevat resurssit ja budjetti?”

Onnistuneet asiakaskohtaamiset eivät synny vain myynnin ja markkinoinnin toimesta. Järjestelmilläkin on väliä. IT-johdon on pystyttävä käyttämään heille suunnatut resurssit mahdollisimman hyvin myynnin kehittämisen hyödyksi. Minkälainen suorituskyky verkkokaupallamme on? Kuinka nopeasti sivut latautuvat? Pitääkö lisätä resursseja, jotta asiakkaiden käyttökokemus on miellyttävä? Millä laitteilla verkkokauppaa käytetään? Pitääkö panostaa verkkokaupan mobiilikäyttöliittymään? Millä selaimilla verkkokauppaa käytetään – mille selaimille verkkokauppa tulee ensisijaisesti optimoida?

Analyyttinen asiakaskohtaaminen ja rakettipoika

Asiakas: “Mitä tuotteita suosittelisit minulle?”

Viimeisenä vielä se tärkein: verkkokaupan asiakas. Nykypäivän fiksu verkkokaupan käyttäjä on tietoinen jälkeensä jättämästä datasta. Kuten Harvard Business review -raportissakin viitataan, tämä nostaa myös asiakkaiden odotuksia palvelua kohtaan. Jos asiakkaiden jokaista klikkausta seurataan, miksei myös asiakas voisi hyötyä tästä?

Kasvotusten tapahtuvassa myyntitilanteessa ammattitaitoinen myyjä osaa nopeasti lukea asiakkaan aikomukset ja mieltymykset ja sopeuttaa myyntipuheensa näihin. Lisäksi myyjä saattaa muistaa, mistä asiakas on aikaisemmin ollut kiinnostunut. Digitaalisessa asiakaskohtaamisessa nämä asiat saattavat helposti unohtua tyystin. Pahimmassa tapauksessa kaikille asiakkaille tuupataan samoja kampanjoita, promotoidaan asiakkaille täysin vääriä tuotteita tai tehdään tuotesuosituksia liian kevyen laskennan pohjalta: ”80% asiakkaista jotka ostivat maitoa ostivat myös lihaa. Kiinnostaako?”

Onnistuneessa digitaalisessa asiakaskohtaamisessa hyödynnetään dataa ja automaatiota aidosti henkilökohtaisen kokemuksen synnytämiseksi.

Näiden kysymysten valossa on hyvä hetkeksi pysähtyä arvioimaan oman yrityksesi analytiikan tasoa. Kerätäänkö yrityksessäsi oikeaa dataa? Tehdäänkö kerätyn datan perusteella tulkintoja ja toimenpiteitä asiakaskohtaamisten parantamiseksi vai katsellaanko vain edellisen viikon myyntiraportteja viikosta toiseen? Kuinka moni raportti on tänään lisännyt tietämystäsi? Ja kuinka monen perusteella olet tunnistanut kehityskohteita tai tehnyt viisaita päätöksiä?

Samasta aiheesta ajatuksia tarjoilee Harvard Business Review 2014: The New Marketing: Real-Time, Relevant and Engaged. Lataa aineisto täältä omaan käyttöösi.

Lue asiantuntijoidemme kirjoituksia analyyttisestä asiakaskohtaamisesta: