As a software developer, it's often easy to think that all software should be bespoke. However, in a business environment there are rarely sufficient resources to sustain that model. There is also little value in re-inventing wheels ad infinitum. But - if you go completely to off-the shelf software, you are indulging in (Tom Peter's words, not mine) 'imitation, not innovation'.
I have a theory (no doubt derived from lots of other people) that if you have no differentiating competitive advantage, no "thing" that you do better than anybody else, then you are doomed to compete on price - and only the lowest-cost producer will survive that battle. The trouble with benchmarking, 'world's best practice' and other stuff like that (maybe Six Sigma as well - I don't know enough about it) is that you are just doing what somebody else has done, and the chance that you will be the best at doing it is minimal.
Several commentators advocate the outsourcing of anything which is not core to your business advantage, your 'buzz'. I asked a business strategist one day what would happen if after stripping away all those things which didn't give you a competitive advantage, there was nothing left? The answer? - find something that is or find something else to do.
So where does software development fit in this discussion? Given that it is my livelihood, I guess I am inclined to find a use for it - to a man with a hammer every problem looks like a nail.
First, let's place some limits on the topic. My view here is of software sourced for the internal use of a business, i.e. not software that an organisation has developed as a product for sale, but systems that it uses to support its manufacturing, sales, service provision etc. In this view, business software (however it is sourced) exists only to support business process - if it fails in that the company is likely to fail also. This is one of the driving forces behind the move away from bespoke, internally-developed software in favour of off-the-shelf packages.
Indeed, given the constraints that an internal development effort works within, it is unreasonable to expect that it could cover ALL business software functions - there IS a place for packages. Equally, if a business is interested in innovation, there should be some processes that don't fit into a package - things which are genuinely 'outside the square'. If not, why not? - that's where the future lies ...
So how to make the distinction - where do you draw the line and say "this is where we start doing it ourselves"?
(Thought you'd never ask - cue the trumpet fanfare)
Welcome to what I call the Definition:Differentiation model (there had to be a model, right?).
Glossary: "definition" refers to the extent that a process or function is understood, defined, documented. A process that is prescribed by legislation or regulation is well-defined; a process where there exist Standard Operating Procedures, work instructions or a comprehensive manual are well defined - they have "high" definition. A process which is new, changing, poorly understood, flexible, innovative, unusual; this has "low" definition.
"Differentiation" refers to the extent that this process or function is different to the way the rest of the world does things, and how much this different way of doing things provides an advantage to you. In most developed economies the way people get paid is often similar across companies, because there may be regulatory prescriptions for rates of pay, retirement plans, occupational health and safety etc., and payroll is rarely a competitive differentiator - it has "low" differentiation. Some new, innovative, not-easily-replicated way of delivering a product or service that doubles revenue - this has "high" differentiation.
(clicking on the pic will probably make it easier to read!)
So what does the model suggest? That processes with low definition and high differentiation are candidates for 'bespoke' supporting software (which in a small business may be no more than some clever spreadsheets - suitably backed up, documented etc.). At some threshold, the definition gets better, and the advantage less - so this may be a process where you feel the risk of exposing some intellectual property is low enough to (e.g.) outsource the development - maybe even offshore it. Travelling further along either or both axes moves you into the realm where (particularly) there is no advantage in doing things differently, and the process is so well-known that there is negligible risk of competitors knowing what you're up to - satisfy the requirement with off-the-shelf software, or at the margin - outsource the process itself.
Where the lines get drawn will depend on an individual business' strategy and circumstances - but draw them somewhere! If you don't have innovative processes or activities happening that require internal support NOW, you may not have any processes at all LATER. There also has to be a stream of these activities, because eventually other people will work them out, and negate in some way the advantage you have at the beginning - so you have to keep doing it. In the terms of the model, as the definition improves and differentiation decreases, maintenance and support of the supporting system can be outsourced, and ultimately the function will begin appearing in a software package.
What does this mean for internal developers? First - find yourself an employer that innovates. Second - keep on top of new technology and new ways of using existing tech. Third - while there may be less of you, you should be working on new, interesting and exciting projects, where your knowledge of the business and your position within the walls give you an advantage over external providers. And if that doesn't sound like fun, I guess you could always become an SAP administrator ...