Build an ERP from scratch? Are we crazy?!
July 2, 2010 3:46 PM Subscribe
Our 50-person company has decided to move to a new ERP system, and here's the kicker...it's been decided to build one from scratch. What's a good/best way to track all the info necessary, from general requirements to specific requirements and ultimately to bug reports and change requests?
The first time we switched ERP systems this several years ago, we used everything from Word docs to spreadsheets to email to paper. It was convoluted and difficult at best. Now that we're looking to build one from scratch, I need to make sure we're more organized than ever.
My first thought was to start with some sort of ticket system and go from there. I've searched the Mefi archives and will probably take a look at Trac, Bugzilla, and Fogbugz, but to be honest, I'm not sure I'm on the right track. The developers that helped us make the original ERP switch were on Basecamp, but we hated it. It was too complicated and allowed too many tasks to slip through the cracks.
There will only be a small group of people (maybe 2-3) "managing" this project, getting input from all depts and doing triage, prioritization, etc and coordinating all the tasks with the developers.
Project management skills aside, what're your recommendations for the software to use to track everything? Should we go with a ticketing system? Or use a more full-blown CMS or something?
The first time we switched ERP systems this several years ago, we used everything from Word docs to spreadsheets to email to paper. It was convoluted and difficult at best. Now that we're looking to build one from scratch, I need to make sure we're more organized than ever.
My first thought was to start with some sort of ticket system and go from there. I've searched the Mefi archives and will probably take a look at Trac, Bugzilla, and Fogbugz, but to be honest, I'm not sure I'm on the right track. The developers that helped us make the original ERP switch were on Basecamp, but we hated it. It was too complicated and allowed too many tasks to slip through the cracks.
There will only be a small group of people (maybe 2-3) "managing" this project, getting input from all depts and doing triage, prioritization, etc and coordinating all the tasks with the developers.
Project management skills aside, what're your recommendations for the software to use to track everything? Should we go with a ticketing system? Or use a more full-blown CMS or something?
Best answer: Go and read a bunch of stuff about Agile Development. You don't have to follow all the guidelines and drink all the kool-aid, but you do have to understand why people choose to do agile project management and why you do or don't want to follow their lead.
What software you use is really a secondary issue to how you want to manage the project. Some really well managed projects are done with postit notes on a white board.
That said, in our organisation we usually have a spreadsheet for the big overarching issues, and FogBugz for the nit picking detail. Not having things fall through the cracks is a matter of discipline on the part of the PM, to actively go hunting for things falling through cracks and haul them out again.
posted by emilyw at 4:02 PM on July 2, 2010
What software you use is really a secondary issue to how you want to manage the project. Some really well managed projects are done with postit notes on a white board.
That said, in our organisation we usually have a spreadsheet for the big overarching issues, and FogBugz for the nit picking detail. Not having things fall through the cracks is a matter of discipline on the part of the PM, to actively go hunting for things falling through cracks and haul them out again.
posted by emilyw at 4:02 PM on July 2, 2010
Don't walk away. RUN. It's insane to build a bet-the-company application with no experience or expertise, particularly when no one seems to know what will work or scale up.
There are plenty of turnkey systems and experts to evaluate what you need. Save yourself and the company. Otherwise everybody will be bankrupt and on the street looking for work.
posted by KRS at 5:02 PM on July 2, 2010 [4 favorites]
There are plenty of turnkey systems and experts to evaluate what you need. Save yourself and the company. Otherwise everybody will be bankrupt and on the street looking for work.
posted by KRS at 5:02 PM on July 2, 2010 [4 favorites]
Best answer: You can easily support a team of up to 10-20 developers with a basic ticketing system. Axosoft OnTime is a decent commercial one, not very expensive and has a highly configurable workflow. The free ones you mentioned should work fine for managing the tasklist.
Requirements management is a different software area. You can get pretty far just putting requirements into word documents. QualityCenter is the standard for requirement management and testing, including traceability of requirements through to tests, but it will cost you in the tens of thousands. I've recently conducted a requirements management search in my workplace, and there do not seem to be many great tools out there that are cheap.
An interesting idea might be to try and use the ERP application itself as you move forward. This usually causes developers to add nice features to the system. I have a lot of experience in building such an in-house system, MeMail me if you have more questions.
You really haven't mentioned the number of people involved in the project, or your budget, so it's difficult to advise properly.
posted by yoz420 at 5:02 PM on July 2, 2010
Requirements management is a different software area. You can get pretty far just putting requirements into word documents. QualityCenter is the standard for requirement management and testing, including traceability of requirements through to tests, but it will cost you in the tens of thousands. I've recently conducted a requirements management search in my workplace, and there do not seem to be many great tools out there that are cheap.
An interesting idea might be to try and use the ERP application itself as you move forward. This usually causes developers to add nice features to the system. I have a lot of experience in building such an in-house system, MeMail me if you have more questions.
You really haven't mentioned the number of people involved in the project, or your budget, so it's difficult to advise properly.
posted by yoz420 at 5:02 PM on July 2, 2010
Best answer: I recommend you look at JIRA. I used this bug-tracking software for several of my projects, it's easy to learn, easy to use - and it also allows for logging of features (to be considered in a future version of the sw you are developing, for example) and change requests. The license fees for this product are quite reasonable.
Re roll-your-own ERP systems - I worked with an outfit eight years ago where the company had developed their own system. It can be done. This worked for them for a number of reasons - the company is in a very specialized industry, there was very little turnover in the company (most with 20+ years in the firm), they mapped the ERP very closely to the key departments and functions that they wanted to track within that system. They built it on a stable platform and evolved the ERP as the platform was upgraded.
They made the decision to roll their own after carefully evaluating what was out there at the time, they could have gone with an off-the-shelf system, but they did not want to buy and adapt to their own situation. They made the right call, it worked for them - and they had a small in-house team to support and update as required.
posted by seawallrunner at 8:36 PM on July 2, 2010
Re roll-your-own ERP systems - I worked with an outfit eight years ago where the company had developed their own system. It can be done. This worked for them for a number of reasons - the company is in a very specialized industry, there was very little turnover in the company (most with 20+ years in the firm), they mapped the ERP very closely to the key departments and functions that they wanted to track within that system. They built it on a stable platform and evolved the ERP as the platform was upgraded.
They made the decision to roll their own after carefully evaluating what was out there at the time, they could have gone with an off-the-shelf system, but they did not want to buy and adapt to their own situation. They made the right call, it worked for them - and they had a small in-house team to support and update as required.
posted by seawallrunner at 8:36 PM on July 2, 2010
You could also ask the implementing party for help on this. They probably have a better idea of what to do and how to go about it and might bring a favourite tool, too.
posted by oxit at 12:18 AM on July 3, 2010
posted by oxit at 12:18 AM on July 3, 2010
Best answer: You leave out all the juicy bits....
* how capable are your users? Do they need flashy / well integrated bits? Will they be happy eating their own dogfood?
* what's the design process? Are the capabilities need well known and understood, or is this going to be "guessing games in the dark" trying to figure it out?
* is there buy-in on this from people who have to use it? Can you replace parts of the current processes piecemeal as you go along?
* what's failing in the current system, other than "it's complicated". Every ERP is complicated, since every business is complicated! If managing a business was as easy as making simple software to do it, we'd all be running businesses!
My advice would be Trac for the ticket queue bit, if you have software folk, and hosted Google Docs (including Google Forms, which is great!) for everything else. Partly it's because they're free, and easy to play with while you figure out what it is you really want.
(My real hunch echoes those of many people here, that this is insane, penny-wise, pound-foolish, and likely to destroy the company. As it happens, I think the ERP has those same features!)
posted by gregglind at 8:40 AM on July 3, 2010
* how capable are your users? Do they need flashy / well integrated bits? Will they be happy eating their own dogfood?
* what's the design process? Are the capabilities need well known and understood, or is this going to be "guessing games in the dark" trying to figure it out?
* is there buy-in on this from people who have to use it? Can you replace parts of the current processes piecemeal as you go along?
* what's failing in the current system, other than "it's complicated". Every ERP is complicated, since every business is complicated! If managing a business was as easy as making simple software to do it, we'd all be running businesses!
My advice would be Trac for the ticket queue bit, if you have software folk, and hosted Google Docs (including Google Forms, which is great!) for everything else. Partly it's because they're free, and easy to play with while you figure out what it is you really want.
(My real hunch echoes those of many people here, that this is insane, penny-wise, pound-foolish, and likely to destroy the company. As it happens, I think the ERP has those same features!)
posted by gregglind at 8:40 AM on July 3, 2010
Best answer: If it were me, I'd use Trac. I especially like the integrated wiki. If used correctly it allows you to build linkable documentation as you go and avoid having the additional headache of trying to version Word files.
For the record, I don't think it's completely insane to want to write your own ERP. The problem with COTS ERP software is that it's just that: "Off the shelf." Every business has it's own quirks. Sometimes it's more effective from both a cost and functionality perspective to pay for bespoke development and get exactly what you want rather than buy off the rack and never quite be able to shoehorn your business processes into the software. Just remember Obi-Wan's Second Law of Computing: "If the data model is correct, all things are possible."
Along that vein, if you're going to be one of the architects of this system and you aren't already familiar with Fowler's Analysis Patterns, I recommend it to you highly.
posted by ob1quixote at 12:03 PM on July 3, 2010
For the record, I don't think it's completely insane to want to write your own ERP. The problem with COTS ERP software is that it's just that: "Off the shelf." Every business has it's own quirks. Sometimes it's more effective from both a cost and functionality perspective to pay for bespoke development and get exactly what you want rather than buy off the rack and never quite be able to shoehorn your business processes into the software. Just remember Obi-Wan's Second Law of Computing: "If the data model is correct, all things are possible."
Along that vein, if you're going to be one of the architects of this system and you aren't already familiar with Fowler's Analysis Patterns, I recommend it to you highly.
posted by ob1quixote at 12:03 PM on July 3, 2010
It worries me that you cite Basecamp as being too complicated. One of Basecamp's appeals is simplicity. How did you use it, and how did the tasks slip through?
posted by mrgoldenbrown at 5:32 PM on July 3, 2010
posted by mrgoldenbrown at 5:32 PM on July 3, 2010
Response by poster: Thanks for all the advice. Yes, I know not to rely on the software to "magically" keep everyone on track, and the point about the tracking software to be secondary to the project management itself is well taken.
@yoz420: you asked about # of people involved. I'll be lead and I'll have probably 1-2 assistants to help me process and evaluate requirements and manage the project. Input will come from up to 30-40 people (but probably more like 15 actively involved people) who will actually be using the ERP system. On the developer side, we'll probably only have one main contact, and I think there's a team of 4 programmers.
@gregglind: great questions. How capable: so-so. We switched from a green terminal/custom cobol system about 4 years ago to a modern ERP system, and there are *still* people griping.
Design process: I would say we're mostly there as far as needs and requirements.
Buy-in: nobody even knows about this yet except upper management. As for piecemeal, I'm going to have to look into thta.
What's failing: don't get me started. "It's complicated" and vague responses, mainly from accounting, who I'm convinced STILL don't get it and don't want to learn. But they've got the owner's ear and I'm getting off-topic.
@mrgoldenbrown: maybe it was the way Basecamp was set up or maybe its features have changed since then. The developers used it extensively. But we on the "customer" side found it difficult mainly to get summaries. It wasn't too difficult to find out what was going on on individual tasks, but it was hard to get a handle on the bigger picture of what was still pending, being worked on, etc.
posted by edjusted at 4:34 PM on July 7, 2010
@yoz420: you asked about # of people involved. I'll be lead and I'll have probably 1-2 assistants to help me process and evaluate requirements and manage the project. Input will come from up to 30-40 people (but probably more like 15 actively involved people) who will actually be using the ERP system. On the developer side, we'll probably only have one main contact, and I think there's a team of 4 programmers.
@gregglind: great questions. How capable: so-so. We switched from a green terminal/custom cobol system about 4 years ago to a modern ERP system, and there are *still* people griping.
Design process: I would say we're mostly there as far as needs and requirements.
Buy-in: nobody even knows about this yet except upper management. As for piecemeal, I'm going to have to look into thta.
What's failing: don't get me started. "It's complicated" and vague responses, mainly from accounting, who I'm convinced STILL don't get it and don't want to learn. But they've got the owner's ear and I'm getting off-topic.
@mrgoldenbrown: maybe it was the way Basecamp was set up or maybe its features have changed since then. The developers used it extensively. But we on the "customer" side found it difficult mainly to get summaries. It wasn't too difficult to find out what was going on on individual tasks, but it was hard to get a handle on the bigger picture of what was still pending, being worked on, etc.
posted by edjusted at 4:34 PM on July 7, 2010
This thread is closed to new comments.
posted by edjusted at 3:51 PM on July 2, 2010