[Event] Composable commerce & SAP CX solutions: build the future of your digital platform

WORKSHOP 1
Build things that work first whatever is the technical approach.
Build trust with business.
Selling composable to business is mandatory to get budget.
People first, build your Dream Team!
Transformation is mandatory for all people involved in Digital projects.
Budget Control is better but not a prerequisite.

 

WORKSHOP 2
Composable is a game changer for the Make or Buy criteria.
Guiding principles for Build could give an advantage but cannot be a diktat in our organizations.
Shared components bring opportunities in the Customer Journey...
...but also side effects and impacts to be anticipated!

 

WORKSHOP 3
The right governance for managing the roadmap must correspond to the maturity of the company, and it will evolve.
Some digital assets are mandatory before governance can be applied.
Communicating successes is mandatory, innovation is key to get trust from ExCom and Business.
Awareness on IT/Digital from making-decision people is key.

First, build things that works, do not sell tech !

 

1. Trust with business

 

• Get trust of the business with a first success, show results, communicate.
• Do not be over-ambitious, build and show progressive successes.

 

2. Getting Budget

 

• Get business & Excom sponsors aware of Digital, explain the importance of the information system...
• ... Even if sometimes it is difficult to involve them in technical considerations
• Create components that markets and brands can personalize.
• Provide solutions with high level of personnalization for markets with budget and resources and ready-to-use for smaller ones.
• Be able to provide solutions that fit to countries' capabilities.
• Plan components for the whole company but explain that components can be specialized by brands, countries, branches…
• All decision makers must find an interest in what we build.
• At least, get budget visibility on all digital initiatives or best control the digital budgets in order to build shared components at the company level.
• Control or visibility on budgets would be a key factor of success, but it cannot be a prerequisite because it is not possible in many organizations.

 

3. Transformation

• PEOPLE FIRST, build your Dream Team: good practices, strong core team of experts
• Archi first, before Guiding Principles.
• Gather the best dev and tech experts to build the foundations, the first components.
• Get a good architect, then a good tech team.
• It needs to involve the whole company, so we need to train all involved people for AGILE skills and vocabulary, even business resources.
• Need of a well-defined, organized Transformation Support for agility, eCommerce…
• Identify the best opportunities to help improve: use a good skilled team, a project with many opportunities, a country with a great chalenge..
• Transformation is easier when trust is created.
• Even if we get success with the first (dream) team, it is sometimes difficult to transform the other teams.
• Guiding principles: useful but not mandatory, they can be defined after the first success(es)
• Principles are hard to be produced and once produced, difficult to use.
• Mentoring is more efficient than principles

 

4.Get or buy

• Composable approach changes the criteria of the Maker or Buy, because of the granularity of the components.
• If small components or simple to develop: MAKE. 
• If usage of a small part of a vendor solution: MAKE.
• If too company-specific: MAKE.
• MAKE only if you have the right resources and budgets to make AND to maintain.
• Cost, competitive advantage, talent availability, and sustainability of the component vendor are also criteria.
• Information systems are more and more a mix of BUY and MAKE.
• For BUY & MAKE: challenge the constraints of skills/talent maintenance for the next years.

 

5. Guiding Principles

• Expose every feature or service can be a goal but require a big and complex transformation.
• Defining Guiding principles and making them applied: this rule is too much “black&white” for all. Guiding principles must give opportunity to improve work/quality… but not as strict and mandatory rules.

 

6. New opportunities, new impacts

• Composable opens opportunities, but current organizations are not adapted to consider the whole Customer Journey: too many teams, too many silos, no vision of the consequence of the shared components: the organization needs to be adapted, with fewer people to decide.
• New approach required to anticipate the impacts and the required harmonization (data, UX, interfaces, etc.).

 

7. Products governance & roadmap management 

• Sharing of the backlog, finding the right balance between requirements coming from the Digital and requirements coming from the business.
• Most of the time, we must provide ability for the divisions to add and deliver their own specificities on top of a centralized core-model.
• There may be an in-between to be found, with Single Global Components and Components which are more specific to parts of the organization
• Design systems with flexibility to ensure homogeneity.
• The right governance must correspond to the maturity of the organization; it cannot exist an ideal one, and it will evolve with the maturity.
• Some technical assets must exist in order to give an orientation and some guidelines for the governance (you cannot ask for homogenization if you do not have any design system, for instance, or any frameworks).

 

8. Success factors

• Importance of having Marketing & Communications skills / resources in the Digital Team.
• Importance of having decision makers aware of digital and IT "realities".
• Do communicate on the digital activities, show the successes, communicate on results, on innovations: BUILD TRUST.
• Communications coming outside of IT can benefit more for IT if they come from outside IT.
• Ask your “business inner clients” to communicate.

 

 

BEFORE THE PROJECT, HOW DO WE START?

 

Do we need to have a clear vision of the target to achieve?​
How should we define the roadmap for the project?​
How do we validate the investment / business case?​
Are Cloud solutions changing the way we calculate ROI?​
Should all stakeholders be involved in the decision-making process?​
Big bang or progressive rollout: which is more appropriate?​
What are core model system vs. unique global solution trade-offs?
How should the business units be involved in the transformation process?​
Should the transformation project include the operational teams?​
Which organizational changes are needed to facilitate this transformation?

HOW DO WE LEAD AND ORGANIZE PROJECT AND TEAMS? 

 

Do we break down the existing monolith (peeling the onion) or start all over?​
Where do we start. And why?​
Inhouse / Outsourced / Combination. And why?​
Are there any Vendors involved in the process (e.g SAP)​
Build vs Buy (Any specific guiding principles?)​
Is there a business case made upfront? OKRs? ​
What were/are the non-functional requirements?

HOW DO WE RUN THE PRODUCT AND THE ROADMAP​

 

What lessons can be learned from the build phase in terms of roadmap management?​
How can Cloud solutions meet compliance and regulatory requirements?
Are pilots still necessary? If so, for which scope?​
Should a limited MVP be deployed to replace an older, feature-rich website?​
How can we deploy traditional business milestones while maintaining an agile approach?​
How do we transition from build-phase governance to run-phase governance?​
What approach can work for both large and small markets?​
How can the organization be aligned with digital solutions?​
Which autonomy for markets, brands or branches in an international company?

CHALLENGES AND TRIGGER FACTORS TO EVOLVE​

 

What is our current state? Monolithic, peeling the onion, composable, etc.
What are our main reasons?
Business KPI's, customer churn, performances, scalability, multi-site architecture?
Where did we start? Do we plan to start?
Vendor solution roadmap, end of life, economic triggers?​
Obstacles that we have faced or anticipate?
Corporate vs. local, digital maturity across regions, platform administration and contributing user experience?
Do we have any guiding principles to approach this?
Architecture, technical stacks, assessments, pre-checklists, legals, headless?

​

1. SAP Hybris's broad feature set significantly helped kick-start and accelerate e-commerce initiatives.
2. However, no single solution can cover every need, and relying on extensive vendor customization may be a potential concern.
3. Transitioning from on-premise to cloud infrastructure isn't always necessary.
4. Decomposing the architecture can enhance performance, allow for best-of-breed solutions, and reduce dependency on specific vendors.

 

Where are we today?

• Back-office: The platform is heavily customized to accommodate specific business needs and creativity.
• Headless Commerce: Transitioning to headless architecture with content-driven CMS and fully customizable frontends.
• Cloud vs On-Prem: The current on-premises setup is challenging to migrate to the cloud, which may not always deliver functional or cost advantages.
• Integration: Extracting certain features, such as search, has been problematic.
• Platform Positioning: High SAP costs and significant reliance on IT teams present ongoing challenges.

 

What are our main reasons to change the way we’re doing things?

• Enhance flexibility and scalability to better adapt to evolving business needs.
• Optimize costs, particularly for emerging, small, and medium-sized markets.
• Resolve current platform limitations to improve performance and user experience.

 

Where did we start / do we plan to start?

• Prioritize the integration layer to ensure seamless connectivity and data flow.
• Focus on decoupling key components, such as CMS or PIM, that have direct business impact.
• Evaluate cloud options and performance optimizations to enhance efficiency and scalability

TECHNICAL CHOICES TO BUILD THE PLATFORM

 

​What components are we planning to change?
Pricing, product information, order management, customer management, etc.
Why do we choose them? How did we prioritize them?
How do we challenge them (pricing, scalability, roadmap, etc.)​?
Share some of your challenges (frontend, headless, etc.)​
Impact and choices on the tools? ​
How and where to start?​
How do we onboard internal and external technical teams?

1. Select a solution that aligns with the company’s strategic roadmap and future needs.
2. Composability isn’t always necessary, but it becomes essential when dealing with high volume, frequent changes, or urgent time-to-market demands.
3. Building a composable system may have higher upfront costs, but the objective is to deliver significant mid- to long-term business value.
4. Implementing composability impacts multiple teams, so choosing the right technology is crucial for ensuring cross-functional collaboration and ease of management across the organization.

 

Which components have to evolve?
How do we select the proper ones and prioritize their deployment?

• The most prioritized components are: CMS (+DAM) > PIM > OMS > Search > Pricing.
• Prioritize components that bring direct business value (like CMS, PIM, OMS) and improve the customer experience.
• Criterias: Cost (Pricing Model particulary in SaaS & Ease of Management), Modularity & Composability, Technical debt, TTM, Team capabilities

 

What are the impacts of these tools on us?

• Organizational Impact: increasing number of expterises & skills fragmentation
• IT teams will face new responsabilities
• Impact on business process: TTM Optimized, Enhance system management

 

ENSURE SLA! (UP & RUNNING PLATFORM)​

 

What are our SLA, their priorities? ​
How do we monitor them in a mult-components, multi-hosting solution? ​
How SLA are attributed to the several teams? ​
How do we share the SLA and KPI?
Shared and realtime dashboard, SLA meetings...​
How do we facilitate the run phase?
Like realiability, monitoring, scaling, autohealing, release management, etc.
Do we have a testing approach, a new QA management?

1. Composability require even more observability usage, it is a kind of follow the heartrate during the day and mainly during workout
2. Operating Level Agreement between teams and not on internal SLAs
3. The “availability” term has different meanings and calculations from one company to another and also differs from teams' perspective
4. Focus on services and features monitoring with SLA and KPI business oriented
5. Multi partner coordination is at the same time a pain and key to permanently fix  the root cause

 

What are our main SLA?

• System level uptime / KPIs should evolve to a more CX service availability metrics
• Too few proactive initiatives to unify monitoring, profiling tools and live dashboarding to reduce outages and downtimes (often related to budget limitations)
• A lot of individual initiatives to get alerts whiteout real governance

 

How do we monitor them?

• Green / Red status of applications or partial critical business process auto checks
• Mix of too many tools with fragmented views (too few real user monitoring practices)
• Being up does not mean that the system is meeting the business target and goals. Maybe we are not selling or selling less than expected

 

How do we improve them?

• Improving troubleshooting process to reduce heavy multi partner coordination in incident meeting
• Need of openness from SaaS / PaaS providers on their inside metrics (exemple : ability to use OpenTelemetry standards)
• Cultural changes to focus on a more global fullstatck observability platforms & take advantage from more frontend KPIs (Real User Monitoring data, Core Web Vitals)