I want to draw a line under the BPM/SAP mini-series of blogs. I am more aware than ever about the need to learn more in this area and actually I already know more thanks to people’s responses to these blogs – a few comments and a few e-mails. I hope to spend time in future finding out more about this arena and why it presents so many difficulties.
However, I continue to have this feeling that the SAP folks just don’t explain themselves. It feels like people are constantly telling me: “you don’t understand…”. What I would like is someone to explain please? Dont just tell me I don’t understand. Please, tell me: what is it that is different? What am I missing here?
Until that happens the BPM/SAP world will continue to feel like a secret society of people who “understand it” but will not explain it.. Until then all this is a mystery, SAP will be a box marked “magic happens here.” I’ve looked a some websites on SAP and I’ve looked at some books. The emphasis on results rather than how only deepens the mystery.
So, let me close by posing a hypothesis, maybe some researcher can pick this up and explore it.
I suggest companies buy big application suites one the assumption that:
Cost of Purchase + Cost of Customisation (programming) + Cost of Change Programme
is less than <
the Cost of Developing a Product from scratch
Cost of ongoing licencing + Cost of ongoing Maintenance
is less than <
Cost of Maintaining a Development Team to maintain a bespoke product
You might also add in a saving in management time, headaches from managing software developers, speed to market and a few other variables but that is the basic equation.
My belief – and I have no evidence for this so it is conjecture (don’t you just love blogging?) – is that companies underestimate the cost of installing and customising these big packages, and simultaneously overestimate the cost of developing their own solution.
That second part is probably the most controversial bit. I suggest that when run well these costs are not excessive and not run away. The current crop of development techniques (yes, the Agile and Lean ones) together with modern tools and existing libraries can help contain these costs.
A couple of cases might demonstrate my point….
As it happens, I do know of a company in London which has taken this route. They have four developer using PHP to continually develop their CRM system and other business functions.
A few years ago a company I worked with introduced SalesForce to help the sales team and started to extend SalesForce to marketing and support. At first it looked like a large part of my project would be thrown away as SalesForce replaced it. After many weeks of talking to the third party integrator it became clear there was something we needed and the system wouldn’t do. We developed the functionality ourselves for a fraction of the cost and time it would have taken to have the third party customise (programme) SalesForce. but then, it was a software company which knew how to do these things.