1

I'm doing this one anonymously.

Our company manufactures some kind of machines and also has a software department, which I'm part of. Our philosophy is mostly to have in-house software and components of the machine instead of third-party where reasonable, so we can quickly implement customer requirements.

Most recently, there has been a decision to implement a small Manufacturing resource planning system (with Bill of materials, Material requirements planning, Capacity planning, etc, all integrated with our machines.

In a nutshell, the customer will enter all of his worker schedule, different manufacturing operations and their capacities, transportation capabilities between them, operations in order and time required for manufacturing a certain item or assembly, deadlines for the internal orders, etc. and then the system will tell the customer a production plan - what the operators at any mfg. post are supposed to do, with reports on over- and under-capacity, time estimates, and so on.

I suppose there is also a vision that we'll make this software universal to be able to adapt to different customer requirements, so we'll sell a lot of them.

We're trying to add value to the machine, so the customers will only need to buy this stuff from us and won't need to pay some big software house tens/hundreds of thousands for a real ERP. We'll be mostly selling this to smaller companies (tens of employees), which cannot afford a real ERP and will have all of the of benefits of automated production planning for a fraction of the cost.

But I have a sinking feeling that there is a reason on why this kind of software does cost so much instead of the common greediness of the suppliers - it is complex, takes time to develop. I'm also worried about the "garbage in, garbage out" factor - that the system will not be able to produce any reasonable output unless the inputs are almost perfectly correct, and I'm not sure you can enforce this level of bureaucracy and overhead in smaller companies.

The powers that be think that all parts of this system are manageable (and have already drawn user interface mockups for the screens) and there will be no problem. Maybe I'm the one overestimating, but I don't know... We already have a small part of this implemented and it took about 2 years to get it to acceptable level.

My biggest concern is the underestimation of development time for this kind of system. In reality, we have about 3 developers, one under a part-time contract, and we'll maybe hire one more full-time developer, so about 3 and a half guys in total. No one has any prior experience with something of this scale, we'll have a lot more data, we'll need more customization options, bigger databases and better algorithms so there will be traps waiting around everywhere.

Is all of this unreasonable? How should I voice my concern to my superiors? Will opposing this kind of project look bad and make me seem unwilling or afraid?

user125650
  • 11
  • 1
  • There are MRP/ERP systems out there that cost much less than tens of thousands. – Alan B Apr 03 '14 at 07:51
  • I'm afraid no one can answer your question except _you_. BTW, what will happen if you don't meet the dead-lines? – Mahdi Apr 03 '14 at 08:35
  • Can you deliver in small pieces or do you need to deliver a full system completely before it is usable? If you can deliver small pieces: 1. Staff management, 2. Capacities, 3. Basic work schedule etc. then you might have a much bigger chance to make your existing clients continuously happy. – Luc Franken Apr 03 '14 at 08:45

2 Answers2

3

It is not possible to give a perfect answer without specific details. However, I could make some general remarks.

Yes, software of this kind is complex to implement. It takes lots of programmer time, but even more so it will require a business process analyst type of role that can map your processes to the software. This is often the meat of the work and where most of the complexity hides. Nowadays the decision is usually made to minimize modifications to the software to fit your processes, in favor of modifying processes to fit the software. The reasoning is that this will greatly simplify future upgrades of the software. So be prepared to change the way you do things.

Based on the fact that it took you 2 years to stabilize a small part of this system it is (probably) reasonable to extrapolate that implementing a much bigger part of this system will take much longer.

Sometimes it is better to live with an imperfect system that works.

Mauritz Hansen
  • 289
  • 1
  • 5
1

At first you could try to collect the different requirements from all stakeholder in a brainstorming workshop. Normally this is a good starting point to get a first overview about all the different expectations and use cases. With this you can start to develop a first global picture of the system. It is much easier to discuss your concerns when you know some more fact about the system you should build.

And try to avoid a waterfall model. Try to learn as much as possible about Agile development, test-driven-development and continuous integration. Why?

  1. Using an agile approach like Scrum will force you to iterations with a fixed timeline ( we are using 3 weeks for instance ).
  2. After three weeks you have to show your results to your customers and they are hopefully happy about the results
  3. It is much easier to react on new incoming requirements of your stakeholder because you will meet them after each sprint ( it is easier to change your focus after 3 weeks than after half of a year ).
  4. You can get feedback fast from your stakeholders when their change their mind ( and normally they will ).
  5. When doing so the tests will give you an answer which part of your system is broken after implementing the new requirements / user stories.
  6. The continuous integration approach can help you to see if your build is broken, the unittests are red or other stuff went wrong after each commit / baseline.
  7. This makes your system much more stable and you will not be scared to change things.
  8. All these points helps you to have a working system all the time. Even if you have to deploy something you know your system has already value.
KimKulling
  • 121
  • 4