In the Business Apps Casino, change is afoot. For a long time, one table – software-as-a-service ERP – attracted a limited number of players and fans. However, over the past 12 months, an increasing number of ERP vendors have lined up to place sizeable SaaS bets, while more potential customers are paying close attention to the gambles those vendors are making.
In Forrester ERP inquiries, it’s now the norm for clients to ask us about SaaS ERP. In fact, it’s unusual to field a call where SaaS isn’t mentioned. Firms may be actively considering a future change in deployment model or simply wanting to kick the tires on SaaS ERP adoption, pros and cons, and comparisons with on-premises ERP. They also seek more information about SaaS ERP market players and likely future entrants. In general, what’s changed since a year ago is that companies want to include SaaS ERP options in their assessments.
Each ERP vendor’s SaaS bet differs somewhat from those of its peers, determined both by the type of customers it’s aiming at and architectural concerns. However, there are some shared themes:
Repurposing existing apps. Some ERP vendors began their SaaS endeavors with apps targeted at small and midsize businesses. They’re now working to deepen the functionality of those apps to appeal to a broader, more enterprise audience. There are two key approaches: 1) expand the scope of an existing SMB product and aim it up market; or 2) carve off functionality from a SaaS midmarket apps suite (while retaining that suite) and create a new enterprise app.
Demand for mobility is rising dramatically, but IT support is not keeping up. Over the next 12-18 months, we expect a majority of Asia Pacific (AP) organizations to begin to feel the pain of poor mobility strategies. Now is the time to define and manage mobility as part of a broader end-user computing strategy – this must include desktop virtualization initiatives, including (but not limited to) virtual desktop infrastructure (VDI). But while server virtualization is now accepted as a fundamental design principle and part of any data center implementation or refresh, that doesn’t mean desktop virtualization will follow suit. Long touted as a means to simplify desktop provisioning and management – and hence improve the efficiency and effectiveness of an organizations’ end-user computing strategy – over the past decade desktop virtualization has been driven primarily by CIO’s desire to lower hardware costs – by delaying or skipping PC refresh cycles – simplify application provisioning, and increase compliance and control of desktop infrastructure in areas like data security and patch management. Desktop virtualization doesn’t adequately address all end-user computing requirements since it’s essentially focused on eliminating the client device from the equation. This is particularly true for VDI. Thin (e.g. ‘dumb’) clients won’t work in a world where a growing percentage of users – not just information workers – are mobile and expect access to key resources but also expect those resources to be optimized for the particular device they’re using. With the explosion in device usage and changes in end-user expectations, IT is being forced to expand its focus around end-user computing from ‘control’ to ‘engagement’. Desktop virtualization will remain a key component of many organizatons’ end-user computing strategies, but its role will remain
I get the following question very often. What are the best practices for creating an enterprise reporting policy as to when to use what reporting tool/application? Alas, as with everything else in business intelligence, the answer is not that easy. The old days of developers versus power users versus casual users are gone. The world is way more complex these days. In order to create such a policy, you need to consider the following dimensions:
Historical (what happened)
Operational (what is happening now)
Analytical (why did it happen)
Predictive (what might happen)
Prescriptive (what should I do about it)
Exploratory (what's out there that I don't know about)
Looking at static report output only
Lightly interacting with canned reports (sorting, filtering)
Fully interacting with canned reports (pivoting, drilling)
Assembling existing report, visualizations, and metrics into customized dashboards
Full report authoring capabilities
External (customers, partners)
Report latency, as in need the report:
In a few days
In a few weeks
Strategic (a few complex decisions/reports per month)
Tactical (many less-complex decisions/reports per month)
Operational (many complex/simple decisions/reports per day)
During the past decade, I have worked with many analyst relations (AR) people as well as specialist AR firms. I have never blogged about them in the past, and I have no intention to do so in the future. Earlier this week, however, I saw that an employee of one of the specialist AR firms authored and published a comment on my most recent report: “Global Banking Platform Deals 2011: Functionality”.
This comment gives the impression that my report only provides common wisdom in that it only suggests that “one of the key differentiators for system selection is a strong track record.” The author also explains that this “may be at odds with the current market landscape as new regulations are set to change the way that the capital markets work and vendors are all developing new functionality to cope” – just to mention a few examples.
My perception is that the author either did not read my entire report or preferred to focus on the six-and-a-half-line summary of an eleven-page report – with a comment that is longer than the summary. Why this perception? First of all, the report is about banking platforms, and Forrester’s definition of banking platforms does not even mention capital markets. More importantly, I do not disagree at all with the author’s statement as far as the relevance of supporting new regulation is concerned – just the opposite, albeit more from the perspective of retail/consumer, private, or corporate/commercial banking.
I continue to field a steady stream of inquiries about “mobile CRM.” There has been an explosion of mobile devices and applications entering enterprises through corporate-approved channels as well as via employees who bring their own devices to the office. Assembling all the components of a mobile CRM solution to meet the precise use cases for specific types of customer-facing workers requires navigating a complex set of decisions, including:
Application types. Applications can be native (thick client), Web or hybrid (native plus Web), or cross-platform (mobile middleware or rich Internet client applications). Today, developers build specialized thick-client applications that are downloaded onto PCs or mobile devices. But the rise of HTML5 will solidify the browser as a viable local host for applications. With HTML5, the browser becomes a more capable thin client, accessing services on a centralized, cloud-based host.
CRM applications. All of the leading CRM application vendors focusing on large enterprises support mobile access to their applications, and they are racing to upgrade their capabilities to keep up with the new form factors that mobile workers demand. These vendors and their products include Microsoft Dynamics CRM, Oracle Siebel CRM and Oracle CRM On Demand, salesforce.com, and SAP CRM. CRM suite vendors focused on the midmarket, such as CDC Pivotal CRM, Maximizer Software, Sage SalesLogix, and SugarCRM, also have new mobile solutions offerings.
Poor customer service experiences lead to increased service costs. 75% of consumers move to another channel when online customer service fails, and Forrester estimates that unnecessary service costs to online retailers due to channel escalation are $22 million on average.
Poor customer service experiences risk customer defection and revenue losses.Forrester survey data shows that approximately 30% of a company’s customers (or more) have poor experiences. And even if a fraction of these defect, this represents a loss in annual revenue.
Growing up in the UK, one of the TV shows I remember watching featured Australian artist and musician Rolf Harris. As each show drew to a close, Rolf would quickly set to work filling a large empty board with seemingly random brush strokes of different colors. About mid-way through his painting, Rolf would turn to the studio and TV audience and ask with an impish grin, “Can you tell what it is yet?” As he continued painting, the strokes would finally resolve themselves into a recognizable image like a portrait or a landscape.
When it comes to revisiting billing software and established practices, many firms are reaching that middle phase. While they have the sense of something starting to take shape, they don’t yet have any clear sense of what the ultimate endpoint will be. Is that your experience with your organization and the industry it serves?
Firms are simultaneously trying to anticipate which types of billing will resonate with prospective and existing customers, while also responding to what their peers are offering. Frequently, one or more competitors in a given industry have emerged with a fresh approach to packaging and charging for products and/or services, which often involves some type of subscription billing. However, what tends to remain unclear is whether the billing type in the ascendant is the ultimate market destination or just a midpoint on the way to a completely different billing model.
Last December, I published three things I'd tell your CIO. Since then, I've spent time with dozens and dozens of sourcing and vendor management professionals, CIOs, and leaders of application development and delivery, including last week's Paris Forrester Forums. Most days, I share our ongoing research on what impact today's software-fueled, consumer-led digital disruption has on your ability to meet and exceed the expectations of your customers and the employees serving them. For some folks, software and software development remains a commodity. But for many, the need to deliver great software has taken hold of 2013 planning discussions. With July just around the corner, and as you start 2013 planning, focus on what you need to start delivering great software (remember, software is your business), and keep these three things I'd tell you and your CIO in mind:
Think you developed a secure mobile app? Think again. Many mobile app developers have a naive notion of app security that leads them into believing their apps are secure when they are not. Some developers authenticate users and encrypt passwords and think that they’re all set, but there could still be security holes so wide you could sail a ship through them. The results of releasing an insecure app can include financial loss, reputation tarnish, lawsuits, and Twitter shame.
When designing your mobile apps and mobile backend services, be sure to consider the six security properties of confidentiality, integrity, availability, authentication, authorization, and nonrepudiation (see Figure below). Simply considering how each security property applies to your app won't make it more secure. You will need to perform threat modeling on your design and find solutions to secure your app based on your specific technology and use cases. Don't forget that the mobile backend services must be secure too.
Great apps are generally native apps. I discuss with our clients daily that, given unlimited time and money, every app should be native, as this affords the ultimate in user experience. Unfortunately, budgets rarely use the word "unlimited," so compromises must be made. Commonly, one of the first tactical directions away from native is to the mobile web. This asks users to painfully type a URL on their device and then suffer through a browser experience that takes away from the immersive experience that the app should convey. This all changed with Mozilla Junior, a browser being developed for the iPad targeted directly at the iPad user. Thanks to some outstanding design decisions, the mobile web now has a very bright future:
A browser without chrome. This is the biggest stylistic deterrent to mobile apps. Today’s mobile web experience is always wrapped in browser “stuff” known as chrome (URL bar, navigation buttons, toolbars, etc.). Junior changes this by providing a browser with no chrome at all. This allows you, the mobile web developer, to use the entire screen as your app canvas. Native interactions (swipes/long presses/etc.) can now be fully implemented without fear of accidentally pressing a browser button.