Is Size Important for Enterprise Software?

October 17th, 2014

Doug Hadden, VP Products

Executives at Salesforce.com have been claiming that they will grow their firm to be larger than SAP. They’re “taking on” SAP. This makes perfect sense in the “dog-eats-dog” ERP world. (More specifically, the “ERP-eats-ERP world.) It’s true that legacy enterprise software firms a playing “Whac-A-Mole” with innovative growing companies through persistent acquisitions. The HP strategy to split the company shows the perils of scaling companies to dinosaur size.

What’s the rationale to be larger than SAP? Does Salesforce want SAP’s scale problems? Why get into a game following SAP’s rules?

Sabotaging Scale through Expansion

This might be counter-intuitive to some: the more lines of business & the more vertical markets with more deployment options combined with more acquisitions SABOTAGES economies of scale. There’s a notion that Salesforce can learn from the mistakes of the past to “do it better.” But, Salesforce isn’t doing it much differently than SAP:

  • SAP held off on large acquisitions until recently, minimizing integration & multiple platform support until quite recently. Salesforce has been on a buying streak
  • SAP expanded in multiple vertical markets (26 or so) resulting in difficulties meeting out-of-the-box functionality in many of those markets when the original code was designed for different industries – yet Salesforce sees this as good approach – Salesforce has contained the pig of code customization so far, but can this be maintained should the company leap into multiple verticals
  • SAP has so many UI platforms on the web (the old version, ByDesign, SAPGUI5, Fiori, Lumira, Personas) to confuse users – while Salesforce is throwing functionality like content management and collaboration into forms-based web client (that starting to look like a ransom note) with a completely different Salesforce1 mobile client (don’t get me wrong, I like the mobile client especially for Chatter)
  • Salesforce has opened the platform for 3rd parties, something that took some time with SAP – this sounds like a great way to scale, by using partners, but it also leaves lots of orphan modules and code floating around that can break with an upgrade
  • SAP has implemented more clever ways for customer lock-in – not a good thing for customers, but a way to keep customers paying for maintenance by providing adequate support

Here’s the thing about scale in software development: a single modern platform without legacy code, built on proven open-source middleware requires orders of magnitude fewer product managers and developers to deliver solutions to customers than the alternative of multiple legacy platforms. This is an advantage that we’ve witnessed since making what seemed like a risk decision in late 2006 to redevelop our software as pure web.

The Alternative: Better

This obsession with size seems to be testosterone-driven. You can just imagine the boardroom discussions in San Francisco about “playing hardball”, putting on a “full court press”, and other sports analogies about competition.

Salesforce is plenty large enough today to give customers confidence. So what if Salesforce is not large enough to sponsor the Formula 1, Wimbledon or America’s Cup champion?

There’s a reason why we run our support, business development, marketing and sales organizations on Salesforce rather than SAP, Oracle or Microsoft. It’s better for us.

Salesforce should obsess about better: better value, lower costs, increased productivity, reduced environmental footprint. They do some of this today by helping non-profits. Hiring “old school” ERP types is not going to help Salesforce eek out new “success factors.” Salesforce needs to out-innovate SAP. That means dedicating engineers to develop the new-new, not focused on integrating the old-old and maintaining legacy code bases. And, the not lose sight of the social mandate

Should we Blame Software for Fraud Committed Outside of the System?

October 14th, 2014

Doug Hadden, VP Products

The Malawi government “Cashgate” scandal has brought some focus on the “Integrated Financial Management Information System” (IFMIS) used. All the evidence that I’ve seen suggested that the IFMIS, (not from FreeBalance), was not properly configured to exert sufficient controls on expenditures and payments. And, manual processes were allowed with commercial banks. The manual payments were added to the IFMIS after the fact. The result is fraud of “K92 billion of state funds” and stopping donor aid that represents 40% of the budget for the government. And, this corruption is only for a 6 month period, so there is the suspicion that far more was misappropriated.

Information Systems Holding Back Aid Transparency

October 9th, 2014

Product Management and Economic Incentives

October 9th, 2014

the FreeBalance experience

Doug Hadden, VP Products

One of the byproducts of Washington DC environment of international donors, thinktanks and development NGOs is an education in economics. The notion of “incentives” that motivate actions has become very familiar. And, many within this larger development and public financial management ecosystem make very quick decisions related to perceived incentives. Or, assumptions.

One of the most persistent assumption is that all software manufacturers within the “enterprise” space behave similarly because of the same incentives. The general view in the ecosystem, is that firms like FreeBalance do not have the proper incentives to provide objective advice to governments. The perverse incentive is that FreeBalance, like ERP vendors, wish to keep product development costs down. Therefore, we will recommend that governments use features that our software possesses. And, we will recommend against trying something that our software does not do.

Government professional often think the same thing.

But, the reality is much different. It might be reasonable to conclude that large ERP manufacturers may wish to keep feature requests down. A specialist firm like FreeBalance seeks to learn about functions that our software does not have. Why? Our value is predicated on reducing code customization to almost nil. That means that we seek, within our product group, to uncover government needs to share with all of our government customers.

This does not mean that FreeBalance is willing to build something that ought not to be built. Some governments wish to “pave the cow path” by including inappropriate functionality from previous versions. One does not implement a new information system to perpetuate what wasn’t working before. Some governments wish to implement advanced functionality that is inappropriate given current capacity. (Many civil servants are familiar with the lack of agility from ERP systems and believe that they will not be able to “progressively activate” as capacity increases. That’s not a problem with FreeBalance.)

How do we handle this? We seek to understand the underlying problem that needs to be solved. That allows us to adapt our product roadmap based on customer input. And, to be “customer-centric” does not mean doing what customers ask, but what’s best for the customer. This includes recommending to not use features that are in the software.

Our top incentive is to have successful implementations that achieve goals. Unlike large ERP vendors, we can’t afford failures.

Aid Transparency much like the Phases of the Moon

October 8th, 2014

The lunar eclipse, a few hours before the launch of the 2014 Aid Transparency Index said it all: what may seem transparent could be opaque. Or, at least “red”, as the moon turned a blood red colour in Washington. There’s good news: many donors have improved transparency dramatically. So, there’s hope for the laggards to learn what works and move fast to fully support the International Aid Transparency Initiative by 2015. In other words, progress from new moons to full moons rapidly.

“Mobile for Development”: Challenges and Solutions

October 4th, 2014

Mobile Technology Enables Global Change and Diplomacy

October 4th, 2014

Mobile for Government Needs Process Re-engineering

October 4th, 2014

“Design Thinking” Drives Effective Mobile Application Development for Government

October 4th, 2014

Mobile Technology Growth Linked to Cloud and Social Media

October 4th, 2014