Hi, and thanks for stopping by. I joined Forrester just over a month ago and I plan to post here regularly with some thoughts on the ERP apps arena. I’m hoping this blog will serve as a place for us to exchange views, and I very much welcome your input.
As you know, Forrester is structured around roles, and I’m part of the analyst team serving the needs of business process professionals. My primary area of focus is enterprise resource planning software. I’m currently pulling together my research agenda for 2011, and I was wondering what top-of-mind issues you think I should be tackling.
At a high level, some of the areas I’m considering include:
SaaS ERP and PaaS.
ERP-flavored project management.
I’m also interested in hearing about midsize organizations and enterprises that have benefited from the successful deployment of one of the following:
A two-tier combination of one vendor’s SaaS ERP integrating with another vendor's on-premise ERP.
There has been a lot of negative press and commentary regarding the recent Queensland Health Implementation of Continuity Project (SAP HR and Payroll), which recently experienced a very public failure as many employees were not paid due to multiple points of failure in the project. The recent Auditor-General's Report on the process is damning, spreading the blame across multiple agencies and the systems integration partner, IBM. I make no claims to be familiar with the intricate details of the process, but I have read the report and feel I have a clear understanding of the (many!) points of failure.
While this project did seem to be a monumental failure, I would suggest that we consider two important facts:
A disproportionate amount of the discussion about Agile in the technology industry centers on product development. However, services are an inevitable part of the Agile story. Here are a few examples:
Consulting teams have to adapt to rapid iterations of new core technology. In other words, the professional services arm has to keep pace with the product development team.
Services are a source of value that gets folded into the product. For this process of productization to work at all, the consulting and development teams need to speak the same language, share common expectations about development processes and deliverables, and work at a similar pace.
Agile consulting teams have to work with customers who aren't conversant with Agile. You might be excited about working at an Agile pace, but your client may have no idea what you're talking about.
That last scenario is a common source of frustration for clients. In place of dense project plans, clients often get a sketchier picture of how the project will proceed. Of course, both client and customer know that, the more complex and detailed the project plan is, the less likely it is to accurately predict what's going to happen. As mythical as the project plans can be, there's something reassuring to clients about having them. At the very least, they provide leverage when the consultants don't deliver.