Microsoft Access APQP type database for Process Flow, FMEA, Control Plan, etc.

[AJLenarz]

I have only recently got my feet wet in Microsoft Access. I am blown away with its capabilities and relatively user-friendly abilities. I am looking at possibly creating a APQP type d-base (process flow, fmea, control plan, ect…).

Does anybody else have something similar out there that I could look at and get some ideas? Any assistance would be appreciated.

Thanks.

 

[Marc]

I haven't personally seen anything that complex done in Access but I don't get out much. There is a lot you can do though. How about it folks - anyone seen anything this complex in Access?

 

[Al Dyer]

I've never used, or tried to design, an access database for the entire APQP process although I previously designed and used one for specifically for the PPAP end of APQP.

We now use a canned program for the entire APQP process that is somewhat flexible in allowing us to redefine fields and checklists.

Access is good, but it does have its limitations.

ASD...

 

[wes wiszniewski]

Fmea and Control plans

Integrating Fmea and Control plans into Access aplication is a great idea. I would also like to see adding process map if possible and make part numbers specific. There was software by Software Realities named Sorge Quality System which integrated all these and lot more but is not available anymore.

 

[Howard Atkins]

There is a packaged software that uses does all this on an Access framework.
They give you a runtime version
We have had discussions in the past about PPAP and APQP software

Search for software in the PPAP/APQP forum to see discussions on commercial applications etc.
In general the cost of developing a good implementation can be higher that the cost of purchasing.
It depends what you need.

 

[Icy Mountain]

I created an Access relational database for FMEA from scratch. That way you can put the features in you want and leave out the ones you don't need. Anybody with a passing knowledge of Basic programming can get this done. You can database image files, documents, numbers, entries, whatever your programming skills and experience will allow. I do it myself because I enjoy it, the canned programs generally do more than I want but not what I want, and they are too expensive for what you get.

I also have an Excel Spreadsheet that another friendly Supplier of the Customer gave me. It has the whole PPAP, APQP, etc. in one file with multiple sheets. You start at sheet one with Customer Name and as you fill it in it puts the relevant info on the right forms in the right places. I believe the Original came from AIAG.

 

[Howard Atkins]

There is a DELPHI version of the excel sheet as an attachement at the cove.
Does your version have a relationahip between the flow chart, CP and FMEA, this is the real problem to maintain this unity.

 

[Icy Mountain]

Sorta

The Access database is a nifty tool for keeping all of your FMEAs in one place, updating, adding and printing. No connection to Flow or Control Plan.

The Excel connects flow to FMEA to CP but only in a rudimentary way with the title blocks. It does not connect the flow boxes to FMEA potentials to Control Plan control items.

Wouldn't it be really cool to have a big open source Access APQP database developed here at the Cove. Oh, it gives me a headache just thinking about it.

 

[Marc]

I would LOVE to see an open source solution, but I'd prefer it in MySQL or PostgreSQL rather than Access.

 

[nickh - 2011]

I have seen a number of Access developed FMEA products on the market, but none that are open source. Having developed a number of Access databases in the past, I would offer the following advice:

1. You're probably better off not attempting to integrate process flow charting directly into the database. A more workable solution is to allow the user to upload a flow chart created in another application and have the Access database store it in a controlled directory and just display a link to the file. (Off topic: My preference is to do the flow charts in Excel, since not everyone has Visio, RFFlow, Smartdraw, etc.).

2. Expect problems if the database grows large. I've created some that started with small user bases that eventually grew to several hundred people. There's a reason that Microsoft recommends using it for only a small number of concurrent users (5-10). A pet project can turn into a babysitting headache. This is the kind of situation that gives Access a bad name. It's perfect for small groups, but beyond that it just doesn't scale well.

3. Learn to design disconnected forms. By that I mean that the data in the forms is not live. I think Access calls them "bound" fields when they are connected directly to the data source. Using bound forms can lead to a lot of concurrency issues (two or more users trying to access the same data at the same time). By default, the forms wizards create bound forms, so it is more of a hassle to create disconnected ones.

4. Run the compact / repair indexes at least once a week and even more frequently if the database grows large.