Engineering Firm - Knowledgebase Ideas 3

[123MB]

Hi All

I am tasked with creating an engineering knowledgebase for our firm. In the spirit of knowledge sharing i'd like to know if anyone has tried this and their experiences.

We are a industrial automation and controls firm doing PLC, HMI and SCADA. Our jobs are between AUD $50,000 and $3,000,000 in construction value.

The knowledge base is supposed to reduce engineering hours spent on jobs by:

-documenting solutions to common problems and tasks so that we don't spend time on one job doing what we have already worked out during another job

-be in written 'white paper' form, or PLC program, this is flexible

-be contributed to by all engineers

We have a system at the moment, but the engineers don't understand it and don't like it. No one contributes to it - they don't see it as a resource that can save them time.

I want it to be a data base that references our past projects with the key technolgies in them. The KB will consist of a job with keywords attached to it that reference the main technolgies in the job, i.e. "control logix interface S7-300" etc.

When someone starts a job they check this data base and can start with this code that someone else has done, i.e not re inventing the wheel

 

[eyec]

keep it simple
a bulletin board system is familiar to most and offers ease of use and searching on keywords for your project identifiers

that is what makes this site so useful



Steven C
Senior Member
ThirdPartyInspections.com

 

[rbulsara]

This is more than a full time job and it is an idealistic program. The net result will be far less than the ideal goal.

If this program is thrusted upon hard working people as one more reporting managerial requirement, it is destined to fail. Were the 'would be' contributors ever consulted before coming up with this program or some MBA is getting the credit for it?

Has the company provided additional help, a field assistance to free up time or a secretary or tech aid to facilitate this documentation? If the company assumes that just by asking people to record their work, some how this is going to happen automatically is naive.

Not everyone who solves the problem, would have enough time to or even skills to write it in sophisticated manner. Many solutions are intuitive and difficult to explain to others how they were arrived at or what was the problem to begin with.

Also there are always those folks, and many rightly so, with job security concern whether or not it is real. There may be a couple of smart persons who solve most of the difficult problems and now far less skilled people may take advantage of their skills. The employer must be fair to compensate those who really contribute (not use) to the database better than others.

I know one good company with excellent field techs, except all the good field techs are over worked. A plan like this would definitely help them and the customers. But many of those tech's view it their job security!! They are just happy to keep working overtime.

 

[CharlieGill]

Developing a Knowledge Base takes a great deal of time and effort. For a company that supplies a great deal of customer technical support, it may prove worthwhile economically as it will reduce the number of support call that the technicians will have to respond to personally. Done as an in-house project for internal use, I seriously doubt it will work out.

I would suggest a couple things. First ensure that all project data is kept in a consistent structure so that finding things is straightforward. Second, invest in a commercial search tool. I haven't looked into them for several years but know they exist. This will make all your project document type files available for search. If I am doing a new project that included a molasses cooler and I don't know much about them, I can query for any project that has "molasses cooler" in it. If there is a consistent file structure, I can quickly find the "description of operations" folder and see what might be there.

Drawings, the core of most engineering documentation, don't index well but it should be possible to include a small icon on each drawing that included common attributes for the type of drawing that the designer can fill in in less than a minute. A helper app could be easily constructed to extract these attributes and create small text files containing the key words and a link to the drawing.

This should allow me to search for a drawing of type "P&ID" containing the keyword "molasses cooler".

This should be an IT department project, carefully planned using common sense (well maybe it shouldn't be an IT project ). The engineers should only be burdened with adding some keyword attributes to file formats that cannot be easily indexed.

Good organization of existing data will be the most beneficial and least expensive approach.

Charlie

 

[123MB]

Thanks all for your excellent responses.

 

[IRstuff]

One possibility might be to use the Wikipedia approach, and authors can be given their due credit. Some sort of incentive could potentially be given for articles with high ratings from users.

TTFN

FAQ731-376

 

[BrianG]

We use a Wikipedia approach for our knowledge base. It was slow to get started, so now everyone has been given an objective to contribute at least one article as part of their annual appraisal targets.

It's taking off now: once you get into the mechanics of basic driving a Wiki it's not that bad really, you can almost "just type" - someone else can do the fancy formatting later if needs be. Mind you, it's a challenge to produce better pages / links than someone else, so most people are keen to master more than just the basics.

 

[biff44]

You can achieve a pretty sizeable knowledge base going forward IF certain things are required of the designers. There should be some formal way of keeping track of the design documents (prints, etc). Even before release, some sort of simple engineering change order (ECO) system is invaluable. Four years later, the final schematic, and a handful of eco documents stating (changed R21 from 4K to 7 K, and C34 from 1 uF to 22 uF, to eliminte 2 MHz oscillation in solenoid control circuit output...") is invaluable if you are seeing a 2 MHz oscillation in whatever you are controlling with a similar circuit.

Also, and I really can not believe how few companies do this anymore, you need to have DESIGN REVIEWS. Power supply board ready to build? Have the engineer staple together a simple explanation of how it works, its inputs and outputs, parts list, derating list of key components, and sketches/prints as they exist at the time. Then invite 2-5 other engineers into a room for a one hour review. Record their comments/questiions, and the engineers answers to those questions. Put it all in a big paper folder and file it away for future use.

Releasing a controller design? Do the same with the firmware listed WITH COMMENTS sufficient for the design reviewers to figure out what is going on.

Next time someone wants to design a widget, they can pull the prints/eco trail and the design review documents, and they have 80% of a good design laid out before there feet!

Follow these simple steps and you will your historical data base of past designs to grow upon, AND you will have better designs hitting the street since the review process will catch 2/3rds of the mistakes that are slipping by today!

Rich

http://www.MaguffinMicrowave.com

Maguffin Microwave wireless design consulting

 

[RYoungberg]

We attempted to do something like what you are talking about, but found it to be limited in value. In the end, we use good old Windows Explorer to do text searches of our network files, and we have a specific filing structure to help find information. In addition, our CAD operators create a searchable PDF when they complete as-build drawings, and those files can be searched for comments and details. Since every project has documentation, we don't bother trying to enter keywords or other descriptions; we just let the computer chug through them when we really need to find something.

Randy