Editor’s note
This text was written about ten years ago, when trees were higher an idea to automate one’s own enterprise with an ERP system, developed in-house, didn’t seem so much utopic and anachronistic, as it does today. And although the number of people who are willing to fall into the same old trap has diminished practically to zero, there is still a great deal of enterprises left since those early ages (and even from earlier – from the 90’s) that suffer every day from a congenital deformity of proprietary accounting systems. This is to them.
‘Out of $50 million that they invested in us as of the
end of last year, we spent $30 million on programmers’ salaries. And now we’re in the red.’
Maksim Faldin from Wikimart,
not at all troubled by that fact.
1. The cobbler should stick to his last
Despite the self-evidence of this thesis being established long ago, time and again we see sceptics, who try to prove it wrong with their own experience and shareholders’ money, doubting that creating financial accounting systems is a job for qualified professionals, as is the case with any area of human activities. A classic comes to mind: “no less than 70% of people, who are reading this now, have just tried to bite their elbow." Let’s make a parallel: why not a single company has come up with an idea to write their own OS for office computers or, let’s say, their own Bluetooth driver for their CEO’s iPhone? Or, for example, hire a research team and build a lab to develop their own aspirin formula for staff sick with flu? That sounds funny, yes. Now, what about ambitions of yet another Construction & Trade Center company to create an ERP system for internal use? A full-scale ERP system, by the way, is only just less complex than a modern operating system.
OK, suppose, you’ve made a decision to perform automation with your own resources. From this point on, we assume, that your enterprise demands have outgrown the productivity of the 1C system (if not, you don’t have to look any further).
Then probably:
- you have a positive experience in managing major software development projects;
- you know the current ERP systems market well, you have a thorough knowledge of advantages and drawbacks of available solutions, their features and architecture, and you are able to design a system that will combine the advantages and leave out the drawbacks of the competing systems;
- you have a deep understanding of market trends and where the major players are going – with an outlook for a few years ahead (for the period of development and installation of your solution);
- you have a team of qualified professionals, the ones who are qualified in developing applications for modern DBMS on modern platforms. You are also highly competent in defining and assigning objectives, in assessment and motivation in this rather specific area;
- you fully understand, even before the start of the project, what kind of result you want. You have a Gantt chart with calculated resources which shows, that the cost of your solution will be significantly lower than the cost of installation of an industrial solution (and taking into account risks – at least three times lower);
- you are sure that during the development you’ll be able to ensure proper quality of coding and documentation – enough for new programmers, who come in as a result of inevitable staff turnover, to seamlessly get involved in the development and/or support. Training of new employees is working well.
Is it a yes? Congratulations.
We recommend you consider achieving your ambitions in software business.
Is it a no?
Then let me voice a few assumptions (however, supported multiple times by rather expensive marks on foreheads of those who like stepping on the same rake):
- you’ll need at least two or three times as much time to develop your solution. You’re thinking a year – a year and a half? Think three to four years and you won’t make a mistake. There’s an over 50% probability (if we’re talking about a full-scale ERP system, and not another Excel-based warehouse piece of software) that your project will never reach commissioning stage;
- an uncontrolled growth of costs results from the previous point. We’ll also note, that in 100% of cases, workforce requirements increase in the course of the ‘project’ execution. So go ahead and multiply their number by at least 2 (and ad inf);
- you’ll have to freeze all changes in your business, for the obvious reasons, for the period of development. Do you think your competitors will sympathize with you and also wait?
- the solution will turn out crumby and ugly. It’s just like a car made in a garage by a DIY enthusiast, that differs not only from a Mercedes, but even from Russian Lada cars. There’s something to be proud of: so much effort was put into it. “And what about driving?" “Oh, that’s secondary." Applied to our case – every time you want to implement changes in business into your accounting system, you’ll hear something like ‘We can’t do that’, ‘Well, I guess we can try, but I can’t tell you the time frame. Maybe you’d better come up with something else?’, ‘No, connecting that type of equipment was not stipulated when the system had been designed.’ As a result, you’ll have to align a real-life business with ridiculous restrictions of an unprofessionally designed and poorly developed system.
- inevitably, you’ll have to depend on several programmers headed by a development manager. Do we have to draw a picture, what it will develop into?
Well, and like they say: ’all of that and for what?’
“No comment" section: CRMa real-life episodeCRM