thumbnail-5437d71ad309c9e2a6832cd471b27522.png

What you need to know about platform integration: A Q&A with Brian Walker

26 shares

By Greg Williams

Today, every business is a digital business, but taking the leap to transform your organization so that’s it’s fit-for-purpose is a daunting prospect both for those building a platform from scratch and those re-platforming from a legacy system. Where to start? And how to avoid the common pitfalls that can derail a project and blow its budget, causing executives to question its implementation?

I spoke to Brian Walker, a global expert in e-commerce platforms who leads strategy, marketing and ecosystem at SAP Hybris about lessons learned from helping a wide variety of companies implement platforms that will evolve alongside the customers’ needs, deliver great performance and help organizations optimize their business for the future. Here, Brian offers some thoughts on what every business needs to know to ensure a smooth transition. 

Greg Williams: You have a client who wants to embark on a platforming or re-platforming project with you. What are the first steps in that journey?

Brian Walker: First and foremost, customers are going to find the most success when they don’t try to boil the ocean – don’t try to accomplish too grand a scope to begin with. When these sort of projects are funded there tends to be a pent-up demand for new features and new capabilities, everyone’s very eager to see a whole slew of things addressed. This is natural, but it is really important that companies do not try to meet all their objectives through a single project. The way to view it is as a program that is on-going. In fact, it will never really be done as these capabilities are going to be foundational to how you engage and serve customers.

GW: So the first rule is, don’t rush?

BW: There can be a sense of urgency because the landscape is changing so quickly, and many if not most businesses will feel like they’ve fallen far behind by the time they get started. But when they try to accomplish too much, they don’t have good governance, and that’s where ‘scope creep’ rears it’s ugly head.

GW: Which is?

BW: An evolving and poorly defined set of requirements that introduces changes midstream. Typically this is caused because stakeholders can’t define what they want until well into the project, or business processes are not well understood. Too many cooks in the kitchen can mean that what you’re trying to accomplish becomes a moving target, which inevitably leads to budget overruns and significant delays. This then erodes the confidence of everyone – including upper management – as to the likelihood of success. That’s when people start asking: “Is this ever going to pay off?” So it’s really important that people see quick time-to-value, that they see progress – even if it’s somewhat limited in scope compared to what you ultimately want to achieve. This is where project governance and discipline is so important – to keep projects on the rails.

GW: What other lessons have you learned?

BW: It’s really important to focus on and define the interfaces between the systems in your landscape. Let’s say you’ve got your core product that delivers data from the back end, or you need inventory data or access to customer data from multiple systems. Defining the interfaces and investing in scalable, highly repeatable standardized interfaces enables you to move much faster later.

When the work is done inside the scope of a large project, but there’s not enough time dedicated to the proper design coding and testing, workarounds or hacks around those interfaces that will cost you later can easily creep in. This is another place where very often, there are cost and time overruns.

Best practice is to do those interfaces in advance. Before a large implementation occurs, create those APIs that enable you to connect multiple systems. Define those interfaces upfront and invest time to properly integrate your existing systems so that they’re in scope with these newer solutions that you’re adding.

We’ve invested in some integration tools that enable SAP customers to dramatically streamline that part of these projects whether you are integrating to SAP or non-SAP systems, but it can still a stumbling block that many companies are going to encounter as they embark on a program like this.

GW: What else should be avoided?

BW: Typically with large projects you’ve hired a consultant firm that is billing you thousands of dollars a day – you’ve got systems architects, developers, business analysts, a whole army of people, plus all of your internal resources. Yet work hasn’t even started on defining the user experience. Everyone’s standing around saying, “Well we can’t really start work until we know what it should look like.”

Defining and designing the user experience can start well in advance of the systems implementation. Sure, there will be a rationalization process to ensure the design can fit the project or to phase the features, but overall this can streamline a project considerably. Typically, there’s just a three-week window in a project plan for user interface design. And it is often at this point that everything goes sideways when senior management or a key stakeholder suddenly gets involved. Maybe they did not know quite what they wanted, but they know they don’t want that! Then the project grinds to a near stop as the design issues get worked out. Not good. With a bit of planning, it’s a completely avoidable situation.

GW: Plans and timelines can be agreed, but I imagine that sticking to them is a whole other challenge…

BW: You need someone to act as a guard dog over the scope of the project who is absolutely committed to delivering it on time. People can throw around ridiculously aggressive timelines for, say, a large commerce implementation or a large marketing system. The system itself might not necessarily be large, but they’re transformative projects that affect every part of the business. There will always be a project plan – you need somebody who is firmly guarding and managing it but is also willing to cut the scope of things to bring the project in on time. As I said earlier, you’ve got to see it as a program versus a project.

GW: And who should that person be?

BW: Where I’ve seen the most success is where a very senior independent project manager is brought in. It shouldn’t be someone from the consultancy firm that you’ve hired to do the systems implementation, and it should not be someone working for the IT team or even the business stakeholder. You need someone who can deliver the news straight and who’s only goal is keep the project on track. 

GW: What if it’s the launch of a completely new site?

BW: The biggest challenge for a new site is that sometimes the plan and the scope of the project don’t account for the business process change. Everyone who’s engaging with the new system has got to know how to use it. They may be coming off a fairly crude, highly manual way of managing their website, their sales process, or marketing. Chances are that the new site and system is going to be a whole lot better, but change is hard. It is tempting to want tools and systems that do things “like it works here”. This can easily lead to scope creep once again.

However, if they don’t know how to use the new system and there’s no content, the process grinds to a halt. The content required – product content, customer data, site content and so forth – often hasn’t really been accounted for. You need to be building content for the new site so that it’s ready to go once the system has been implemented. These are obvious things that end up creating cost and time delays that can be easily sorted out in advance.

GW: SAP Hybris has evolved over the past several years. Can you take us through that journey?

BW:  Hybris started out focused on commerce solutions. It soon became one of the world’s leading platforms for businesses to run large scale e-commerce online and on mobile devices – an omni-channel commerce platform able to manage and support all channels.

That evolved to the point today where SAP Hybris solutions cover the entire front-office, from customer experience, commerce, billing and marketing to tools for sales- and service-people both in contact centers and out in the field.

Ours is a very comprehensive set of solutions that work together – or stand alone – to help a diverse set of customers across the globe with how they engage and serve customers. So we’ve grown from being a commerce platform that was oriented towards transactions to something more all-encompassing that offers customer engagement solutions.

GW: E-commerce is moving incredibly quickly. How have you updated it to handle the fast pace of modern commerce?

BW: There is a long list of things we have done to support rapidly-evolving business requirements, not only for e-commerce but across all channels and front-office capabilities. One thing I would like to highlight that is a more recent innovation is the launch of our new micro-services platform, SAP Hybris-as-a-Service – or what we call YaaS. This platform environment enables developers to launch microservices to extend and support unique requirements in the cloud. Developers can use their language of choice with no vendor lock-in to write, test and launch new services in the cloud. And perhaps even more exciting is the marketplace we are enabling for partners, independent developers and even customers to sell these microservices. It is a very disruptive solution, and it will be very exciting to see how it evolves.

 

 

 

Greg Williams
Share this:
26 shares
April 26, 2016
Greg Williams

Sign up for insights, trends & developments in ecommerce.