Why FluentCommerce OMS as Order Management System?

We decided to use FluentCommerce OMS as the default Order Management System for Emma. The decision was taken by the team after extensive research, discussions, and testing because of the good balance it offers in terms of feature coverage, flexibility, extensibility, developer experience, and lowest cost compared to the other solutions. In summary, these are the deciding factors for FluentCommerce OMS:

• Best coverage of the main business requirements.
• Highly scalable due to microservice-based and cloud-native architecture.
• Best configurable — not customizable — system offers high flexibility with changing business requirements.
• API-first approach to enable better integration and interfacing with other systems at Emma.
• Lower licensing cost compared to competitor solutions.

Why Pulpo WMS as Warehouse Management System?

While researching Warehouse Management Systems we learned that similar to other more conventional areas of ‘enterprise software’ (e.g. ERP, CRM, etc.), this domain is pretty much dominated by legacy third party software companies, running software that was often built in archaic ways — quite the opposite of what we are aiming at for our new tech architecture. Different from the other business domains we had an external specialist consultancy support us in the initial collection of requirements, solution research and evaluation of alternatives. As Emma doesn’t own heavy assets like production facilities or warehouses but partner with specialist 3rd party companies in the respective countries, the topic is almost a ‘greenfield’ — meaning entirely new — for us. In the past, we also did small customizations you can consider WMS-ish built in the legacy E-Commerce backbone, but overall speaking we are not replacing an existing, dedicated system of Emma but extending our reach of tech-driven processes into the domain of our partners’ warehouses with a new one.

Out of the more than 100 different vendors and solutions on the longlist, we condensed a shortlist of only two modern systems qualifying against Emma’s high architectural requirements. Not surprisingly one of those two selected, Pulpo WMS, is developed by a startup company and thus very fresh in the game. Deeply evaluating the two against each other, we eventually decided to go with Pulpo WMS for the following reasons:

• Less total but more relevant pre-built feature set for Emma’s specific use cases.
• Possibility to flexibly extend the feature set according to Emma’s operational needs, from both sides, Emma and Pulpo.
• Approach to go live fast with something small to begin with and adapt is following Emma’s core principles.
• Ability of the vendor to implement a first test scenario 6 months (!) faster than the competition.
• Overall significant better cost projection (both one-time and recurring) compared to competitor.
• Built with modern software engineering principles; almost MACH-compliant system architecture (e.g., API-first).

As the deployment of a WMS, more than most other of our business domains, is very physically impacting operational processes and people at warehouse facilities (and again, these are not Emma but partners) conducting a Proof-of-Concept (PoC) test meant a physical trial at one of our partner’s warehouses. First results look very promising, and we believe this will play a big part in the overall harmonization and streamlining of our operational processes throughout Emma’s value chain.

Why Microsoft Dynamics 365 F&SCM as Finance and Operations Core?

When growing from startup to scale-up, for the longest time you don’t even have an ERP — ‘Enterprise Resource Planning’ software. Your business scales and the Excel spreadsheets you started with just keep growing and it might be surprising to see, but you can run a business with this kind of (process-wise) unstructured tooling quite well in the million Euros of revenue. The problems kick in when your business grows in complexity as you expand in more markets, enrich your product categories, establish new legal entities, vertically integrate with partners, etc. It is when the value-driving processes of your operation leave the trivial territory where manual tooling reveals it proneness to error and fragility. Typical symptoms of this are tedious and slow collection of data to answer simple business questions as well errors and incidents piling up and, as there is no better solution available, your imminent reflex is to solve more errors manually with more workforce.

As laid out earlier, our business grew (and still grows) near to exponentially which in turn means that errors correlating with regular business operations (like the afore mentioned coming from manual tooling) also scale similarly and would require the same amount of manual fixing. Yet hiring (and also sourcing) for your teams usually progresses in a linear fashion and pushing your organization into hypergrowth can have fatal consequences, resulting from the fact complexity of organizational collaboration also grows at 2n. Obviously, this is a futile fight and a dead end.

Already almost 2 years ago, we decided to implement an ERP-system and chose a mid-sized system corresponding to the business status quo at the time, i.e. Microsoft Dynamics 365 Business Central. However, only after a year, we learned that we already outgrew the Business Central version of Microsoft Dynamics in terms of business volume. So, back to square 1.

ERP-system integrations are very massive project efforts. At this point we could have gone into ‘full market research’-mode, meaning we would collect and refine our business requirements once more and evaluate which of the major ERP-systems of the well-known vendors would be best fitting (a.k.a. searching for the global optimum).

Unfortunately, this domain of ‘enterprise software’ is dominated by huge (and I mean HUGE) corporations and there are no modern, disruptive players in the field — at least not for use cases of scale-up companies of our size and complexity (>500mn EUR of rev; business in >30 countries). Evaluating the best fitting solution from these systems with the help of the vendors and their system integration partners can easily take a year — and that is until you know what might fit — implementation takes another 2–3 years.

So, instead we decided to take a very different approach and search for our local optimum. Looking at the solution alternatives we decided to:

1. ‘Rock the boat’ as little as possible for users of the existing system and our ERP-developers, meaning we would stay within the same family of solutions of the same vendor (i.e. Microsoft Dynamics 365). This minimizes the retraining efforts and eases migration efforts as, even though there are no simple upgrade paths between such systems, parts of the ecosystem and data structure are reusable.
2. Purely look at system capabilities from a business requirements point of view, and never — I must repeat to emphasize this — NEVER from the optimal utilization of all integrated modules of such a system. We have very consciously and for good reasons decided for several purpose-fit, openly architected systems in our business domains and the ‘fully-integrated’ claim of ERP-system vendors can also be translated into ‘proprietary monolith lock-in’. This is also why we don’t call the business domain ‘ERP’ but Emma’s ‘Finance & Ops Core’.
3. Not rely purely on an external workforce for the integration (i.e. consultants) but build an internal team and augment with multiple external partners for special subject matter expertise. All software has operations & maintenance and needs further development over time — an ERP-system is no exception here and if it is managing at least parts of your value chain (why else would you even have it?) you want to be able to do this yourself.
4. Strongly challenge the scope to implement and really boil it down to the absolute minimal possible feature set to implement. We don’t need perfect on day 1.
5. Approach it by building a ‘Minimal-Viable-Product’ (MVP) first and then iterate and deliver often in the process. We might not need perfect on day 1, but we need version 1 day after tomorrow!
6. Take care of the project management ourselves. Most integration partners have extensive experience in conducting large, complex, years-long-lasting ERP-system integration projects managed in waterfall-fashion. You will see ‘agile’ statements in pre-sale pitch slides, but there is really no agility at all in such conventional project approaches and usually they revert to old practices almost immediately after contract signature.
7. True agile approaches are novel in this domain and don’t come with best practices. Be bold, push hard and create best practices!

Ultimately, we decided for Microsoft Dynamics 365 Finance and Supply Chain Management (F&SCM), trained, and extended our teams and recently started into the MVP phase of this integration and migration project.

I won’t lie to you. Our approach raised quite some eyebrows and did not make us popular with integration partners. Nevertheless, we are convinced our approach is the right way to go, incrementally delivering value to our business teams in short intervals, learning and adapting our route while we go.

Watch out for upcoming blog posts covering our learnings, successes and fails on this journey.