No Planning Required: Design your own ERP system from scratch?

[vonsteimel]

I work for a small mfg company building a unique type recreational vehicle.

We've been around since the early 70's. In the early 90's the owner decided to try to grasp the advantages of computer technology. However at that time "ERP" system were virtually non-existent. I don't know all the details but the decision was made to start writing our own system from scratch with handful of programming students, interns & new grads. From what the owner tells me, it was a type of spurr of the moment design process. Where he'd walk in every now and then and say "he guys, we need to be able store part numbers".... "hey guys we need to track where these part numbers are stored"...etc

Long story short, this continued on for about 20 years now and has went through multiple different "bases", such as MS-access based.etc and is currently web-based. The owner reckons he's got 7-figures buried in this system but it fails to impress anyone who's ever used it. It does a lot of different things but it doesn't do any thing very well IMO. Whatever the subject is, it requires a lot of extra foot-work to complete the task. To me, it feels like we're basically running 2 systems in parallel; 1 "old school" system running off of sheets of paper, face-to-face discussions & elbow-grease, and the other being the web-based system that is in constant development. And it seems your always repeating tasks to get anything done. i.e. see what the price says on the computer, now go pull the old PO & see what it says; see how many the computer says we have, now go count them in the inventory room.etc-type-of-thing. This tends to really weigh things down.

What I'd like to know is; generally speaking, on a software program as grand as an ERP system, wouldn't some planning be needed so that you'd end up with something useful in the end? Is is typical for software to be designed ad-hoc? I'm a Mechanical Engineer, but from what I know about software dev of this scale is that it generally requires a high level of in-sight and planning? Am I correct in this notion?

Virtually every mfg consultant/production manager that has worked here since I started has been against our custom built ERP software, preferring instead to buy something that is already developed & proven...

However the owner seems keen to continue its development in hopes of having a marketable ERP system when its finished, at the urging of the lead developer. (there has only been 1 developer for the past 6 years)

If we are going to continue the development of this system, what do you recommend? Would the first be to create a requirement specification for the business requirements?
The production manager and I have already done this (see attachment) but the lead dev doesn't seem interested in it. Is this not a basic first step or am I on the wrong track? It is to be used either to develop our current system into what we need or otherwise evaluate various ERP systems, including our own, to our needs. or Both.

Thanks to anyone who has the time to read this. And a bigger thanks to anyone who takes the time to reply.

VS

 

[MikeHalloran]

I think I've figured out where you are.
I really, really, wanted that job before you got it.
Now, not so much.

Not so long ago, I worked for an outfit, call it company R, that had started with a basic POS system that ran on an AS/400, sometime around 1972. It's still a POS, but in a different way. Now it runs on modern IBM hardware, on top of multiple layers of simulation of older hardware, and Linux, but it still runs just as slow and just as badly as it did in 1972. The IT staff has been replaced many times over the years, with both raw new graduates and experienced old hands. Features have been added rather haphazardly, but toward the end of my time there I detected some page numbers that corresponded to pages I remembered from another company that had a complete and 'real' ERP system that had been maintained until at least 1990. I suspect that many of the improvements to company R's system over the years had been stolen, or at least copied, and implemented badly or incompletely.

That other company's system was a full blown ERP system, and it was also a POS, but at least it wasn't riddled with outright bugs; it was just a pain in the ass to deal with. Call them company C.

In both cases, there was, somewhere, a page that let you do nearly anything you could imagine, but each individual user needed to get IT permission to use each individual page, and IT wouldn't volunteer the existence of any useful information, and would actively fight giving permission to use any page, much less tell you it existed.

In both cases, operator frustration was blamed on lack of training, but no training had been provided, ever, and no user manual had been provided to any user, in any format, ever.

The long time users had developed their own maps of the system, sometimes written down, mostly committed to memory, so they loudly protested even the slightest change to any page, because they didn't even look at the screen when navigating; they just pressed keys in a sequence that would always get them to where they needed to be, and any change to the keystroke sequence would cause them to have to actually read, and try to understand the instructions on the screen, which usually made no sense, or were completely wrong anyway.

One thing I noticed about both systems; the modules dealing with HR, business planning, and business management were more polished and more stable than the modules dealing with inventory management and production management. One might infer that IT departments put most of their effort into modules that Top Management will use, and ignore everyone else, or that IT people don't know squat about manufacturing. Either inference might be valid. Possibly both are.

I keep hoping I'm wrong, but it appears that both company R and company C had ERP systems representative of the current state of the art in ERP. ... which is just pitiful.

... and your outfit started without even a known working core, or a an exemplar to copy. Hoo boy!









Mike Halloran
Pembroke Pines, FL, USA

 

[MikeHalloran]

I never did answer your questions...

What I'd like to know is; generally speaking, on a software program as grand as an ERP system, wouldn't some planning be needed so that you'd end up with something useful in the end? Is is typical for software to be designed ad-hoc? I'm a Mechanical Engineer, but from what I know about software dev of this scale is that it generally requires a high level of in-sight and planning? Am I correct in this notion?

You would think that extensive planning would help; you'd be wrong. One example that I won't identify further used an underpowered minicomputer to run a machine. The program binaries totaled more than 30Mb, and the minicomputer had only 64kb of RAM, so much time was wasted shuffling small parts of the program on and off the disk drive. Keypress response at startup was more than 30 minutes. It was so bad that the marketing department engaged outsiders to write a PC program as a front end, to hide the mini's execrable performance, and gave away the PC with each machine.
Another example would be the ERP programs to which I have been exposed, both born in the era of mainframe computers and IT oligarchy. Things change.

Programs are more recently designed, not quite ad-hoc, but Fail-Fast, with 'eXtreme Programming', basically just getting _something_ running as quickly as possible, and working with users to add and delete functions as they use the program, and being fairly rigorous about only including what the users want and need. I was doing it on microcomputers before it had a name.

So there is some chance that a lone IT guy could hammer your current system into something better, and maybe salable, depending on the talent and mindset of that particular IT guy. If he's not somehow (perhaps stealthily) engaging the actual users to help develop the program, success is less likely.



Mike Halloran
Pembroke Pines, FL, USA

 

[IRstuff]

"What I'd like to know is; generally speaking, on a software program as grand as an ERP system, wouldn't some planning be needed so that you'd end up with something useful in the end? Is is typical for software to be designed ad-hoc? I'm a Mechanical Engineer, but from what I know about software dev of this scale is that it generally requires a high level of in-sight and planning? Am I correct in this notion?"

Yes, there is generally some level of planning. However, what I think your company is failing to see is that the totality of functionality as described in your cited feature list is so monumental that no one can actually use it, since it will invariably span document formats from radically different and completely non-integrated data systems. The degree of integration that you are asking for is so high, and across so many different document systems that like healthcare.gov, information requests across so many boundaries will bog the system down and make it unusable for any use other than occasional.

If you attempted to do something from scratch, you'd find that performance requirements would require custom written databases, applications, and interfaces, but such an architecture precludes using any applications people currently use. Or, you'd have to develop translators or converters that would make the main program easier to maintain, but will put you at the mercy of the existing application interfaces and throughputs, similar to what healthcare.gov is experiencing. What this means is that your program would also need to supply a gigantic number of translator programs that can read the data from all the disparate application programs used in engineering and have to maintain them as these applications evolve and update. Additionally, you would need to have an army of knowledgeable support personnel to help users with the problems that would inevitably crop up.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[vonsteimel]

Thanks for the great input guys. It helps to know I'm not alone...
Now to follow up a little;

First off is to brief on why this all came about.
Our 1 IT guy is a subcontractor. He comes here about 6 - 10 hours month. There is almost no engagement with the end users except the owner. (the ad-hoc development continues to this day). The owner himself is not communicating with the end users but is focus on tools he would like to see. Mainly costing information. In other words "put[ting] most of their effort into modules that Top Management".
After starting my job I ID'd the lack of organization (ERP & otherwise) and began to dig into fixing it. This introduced me into the ERP scene and before long I had been swallowed whole into becoming the "communication" link between the end users and dev.

Now the Fail-Fast idea I like but that is not what we have. I had some relatively small changes approved by the owner/president of the company in 2009. They were not completed until 2013.................
The communication, in any detail, with the dev was virtually uncontrolled from my part. He usually showed up a few times a month, many times unannounced and often to deal with IT issues unrelated to ERP dev. I found the most effective means of communication given the circumstance was through documents. Outlines, Screen-shots with some MS paint scribbles.etc

Miscommunication was & always has been a problem. It’s always "this is what you asked for" ---and--- "this is what you get" type of thing. The "what you got" part was often too complicated to be useful. And explanations as to why were full of uninterpretable jargon....

So after the last round of miscommunications, far over-due changes & "this is what you get" 's I had reached the stopping point. But given my position, pushed the project down other channels.
I basically resigned from the "development" of our system and was able to encourage the owner to proceed with reviewing alternative systems to compare features & pricing and to help decide whether to proceed with the development.

One catch; the review team consisted of only 1 person -- the same dev of our homemade ERP system.

So the result was yet another batch of inconclusive jargon. We Reviewed massive companies like SAGE who we could not afford and were almost all compared directly to our system. "do you have button A?" type of stuff. No requirements, specs, outlines.etc were prepared with which to score or evaluate these companies.
More alarmingly, none of the more applicable "out of the box" stuff was included such as Job boss.etc all due to "conflicts" within the IT, cited to yet another jargon filled set of reasons.

But no. I am not ready to quit. Yet....

The system can be made to work. If so, this company has a lot of potential to expand. But given the history of things I feel we must lay out the features we have to have. Deadline them. Let our IT man review them on-site & in-depth. From which real deadlines can be set, along with real expectations (ha ha). Then, once the scope is known, more programmers can be brought aboard and with any amount of hope we can make some real progress.

But hopefully I can get the software review to restart using the newly created outline and a list of more appropriate software companies.

The ERP outline is only the condensed version. The full version breaks down each sub-section into detail and totals more than 30 pages. This is more for our use however so we can remember specific details about the "condensed" outline posted above. More importantly, it is not a requirement spec; it is merely an outline.
This said, it is an outline structured around our own solutions to our own problems. Ones we are not opposed to changing if such changes are justified & proven.
This outline is in the process of being rated where each sub-section of (the condensed outline) is going to be rated. The bottom scores will then be eliminated. The remaining part will then become a quasi-req. spec. to which systems other systems can be rated. Or, it can be used to produce the dev plan mentioned above.

Again, if I'm going to stay on this train, am I on the right track?

Thanks to anyone who has the time to read this. And a bigger thanks to anyone who takes the time to reply. Its a big help.
Fire away,
VS

 

[IRstuff]

A feature list is nice, but what is it about YOUR features that will make someone ditch their existing system and spend the dollars and time to switch to your system? What advantages are you offering that others don't? How are you going to make the transition seamless? How are you going to scarf up the existing databases without forcing your customers to completely re-enter all their data.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[vonsteimel]

IRstuff, I assume you are talking about the marketability aspect of our homemade ERP?
This is secondary to primary objective of achieving success within our own factory. I am not interested in the marketability of our system nor do I believe it has any potential for profit if it ever hits the market. With 7 figures already invested, it would take a miracle just to break even... We have no experience

I'm interested in getting our company operating. We have only 20 people yet have to deal with all the same tasks as GM. International Shipping, Dealer Agreements, QC, Fabrication, Service/repair, letters of credit, counterfeiting law suits.etc Without the help of software to light the load of more straight forward tasks like drawing management I'm afraid the odds for success are slim. Otherwise "running the business gets in the way of running the business..."

I came to the forum looking for tips on how software as complex as ERP should be developed. Our current method is absolute madness, but I don't know enough about it to step up and take control...

Our IT guy, for all his faults, is a pretty sharp guy. Yet speechless about the way he has conducted the dev & reviews. I want to know how its done everywhere else so that we can follow suit.

 

[IRstuff]

Oh, OK, I misunderstood the scenario. Nonetheless, I think you have gotten all the information necessary:
> Detailed requirements, including:
> Detailed throughput constraints, including throughput for user interactions
> Specific requirements governing simultaneous multiple user access to records, i.e., what gets locked, how, and when.
> EXTREMELY detailed interface control documents, including:
> Detailed input/output file format requirements
> Detailed user interface requirements

Otherwise, there are lots of systems engineering process descriptions on the web.

TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529

 

[mcgyvr]

Obviously planning is required.. Your company seems like a great example of why it is...
ERP implementation is a whole company process.. No different if you are buying off the shelf or rolling your own..

Software development/improvement is no different from any other development/design/engineering,etc..
If you don't sit down and plan you will end up with many "oops" moments..

 

[vonsteimel]

mcgyvr,
yes I agree.

I suppose I'm looking for any sources that will validate this in order to provide impetus for change.

I would expect the lead dev to understand this of all people. However he seems more opposed.

Thanks,

VS

 

[mcgyvr]

I'd guess the lead dev is opposed because you are basically telling him that what he already did is basically junk... He thinks what he did is his "baby" and you are telling him his baby is ugly..
You are basically stuck unless you can prove that if you change "X" then "Y" will happen faster/more efficiently.

It "seems" like you have a solution now.. But you don't think its the fastest solution.. So prove it .
However..if the person creating the software and the person paying for it doesn't see the problem then you are SOL.

 

[IRstuff]

Ad hoc isn't necessarily junk, but it's often close. Mathcad evolved from a relatively simple WYSIWYG math scratchpad to an immensely complicated program that was still extremley useful, even if bloated from the the unplanned "feature creep" PTC did a complete rewrite of Mathcad into Mathcad Prime, and is 3 revision numbers in, and is still nowhere close to the functionality of the last revision prior to the rewrite. Given PTC's history in engineering requirements development and management, one might presume that they spent some time developing a detailed requirements document and software development plan. So, nearly 4 revisions in, the effort has been deemed a a joke, because of the time factor, and the still-incomplete functionality.



TTFN
faq731-376

Need help writing a question or understanding a reply? forum1529