On your marks, get set, go.
That to me describes the butterfly in the stomach feeling right before the proverbial mobile race begins. Today, we have found an increasing trend in customers requesting fast deployments of base installs of SUP/SYCLO, and then fast app build and customization. The question is inevitably always asked – “How long is this going to take?” Then that is typically followed up by some colorful commentary somewhat consistent with “ and we need it yesterday”. No pressure right? So, what of the question – How long should mobile projects take?
It’s an easy question. And, it’s a hard question.
It’s easy because customer expectations in the mobile arena is that of “fast”. Fast not in terms of performance (although that is important of course) but really fast in terms of implementation. When it comes to mobile, gone are the days of waterfall, monolithic builds, over years, that consume lots of people, resources, and ultimately – time. And here’s why – customers are always saying they can simply download an app from the appstore in minutes, so why does it take so long to implement an SAP mobile project, or mobile app (SUP or SYCLO based). The question is fair from the customer’s side, but is of the apples to oranges variety. Its all about managing customer expectations. In short, selling the process of how mobile projects really work. There is a fair amount of selling and education that must happen so that customers “consumer” based expectations are in line with typical “enterprise” reality.
Bottom line, you can’t snap your fingers and get an app. At least not a really good one. Especially, not a really good “enterprise” app.
And that’s the hard part of the question. It takes time to implement MEAPs today, and build apps. But, not an insane amount of time. And certainly not the amount of time consistent with typical SAP project implementations, which are the Jurassic park of project delivery methodologies at play nowadays. But it leads to this – mobile projects must be synonymous with quick installs and configs right out of the gate, so that the customer gets VALUE quickly, and can start building or consuming apps quickly.
The other thing to consider in this conundrum is simply comparison to native app building. We need to keep in mind that customers already come to the mobile table with pre-conceived notions, and opinions. Many times comparisons are drawn to provisioning a mobile project or app natively. Certainly the pro’s are there of less overhead and config, and also of complete control over the ui and the OS. So, we find that blending those consumer principles relative to the MEAP reality is the key. How? Fast installs. Faster config. Fast setup. But there are cons to native as well, namely framework provisions (ready mbos/rest services/connectors to SAP not there in native), and also more coding needed.
The more we can show how to hit the ground running with SMP, the more inclined customers will be to say “More please”.
This is the first of a 3 part blog series where I dive deep into the drivers behind Customer’s Mobile Expectations. Today we focused on Time to market. Next up? Cost, soon to be followed by User Experience. Stay tuned, and happy reading.
Leave a Reply