Whether you call them RFIs, RFPs, RFQs* or some other acronym, and whether you are a vendor or a customer, those three letters conjure up the same impression in many minds – pages and pages of detailed questions about a software product’s functionality, which takes weeks to create, days to respond, and weeks again to review.
“Change is not made without inconvenience, even from worse to better.” Samuel Johnson
Do you know how complex Microsoft Word and Excel are?
Because Word and Excel look so easy, people under-estimate how complex other standard systems, like an ERP, can be. If business users knew how complex those two Microsoft applications really are, they would be more thoughtful and careful when embarking on a complex software project.
Part 2: Changing the system as business realities change
Hands up all those who have started implementing an ERP system and not had to deal with changes as the project progresses. No one? I am not surprised. Has anyone gone live with an ERP project and never had any changes afterwards? The reality of any ERP project is that scope changes occur during the project, and after going live it is guaranteed that there will be more requirement changes.
In 2010 there was a debate between some of the major enterprise software influencers and bloggers on whether single or multi-tenancy was an issue for Software-as-a-Service (SaaS) applications. On the one side was Josh Greenbaum who argued that the type of tenancy should not matter to SaaS users; on the other was Phil Wainewright (here and here) and Dennis Howlett whose views were that multi-tenancy is the only way for SaaS software. This debate is still going on.
Part 1: Building a house on a solid foundation
You can hardly miss it these days: questions about why Enterprise Resource Planning (ERP) projects hit problems, or worse, fail, appear on so many websites. I have seen many ERP implementations and thought I had some answers, but it was only after I had been involved in building a house that I could see the similarities between building projects and ERP implementations, and why we don’t see buildings collapsing in the same ways some ERP projects fail.