Integrating PDM Information Into Microsoft Office Programs For Presentable Reports
Integrating PDM Information Into Microsoft Office Programs For Presentable Reports
Introduction
Many of us work with a variety of different software packages within our PdM programs. Some
of these software packages have their own reporting functions and others do not. Often times however, the
people reading the reports want to see the data in a form quite different than those provided by the software
packages. This is where the custom report comes into play. We tend to devise our own reporting styles
that become a recognizable product of our PdM departments. We also tend to do a major portion of our
reporting with Microsoft Office products. This is a natural tendency since most people have Office on their
computers.
One of the most basic ways to incorporate PdM information in a custom report is to use the copy
and paste method. This method offers us a way to insert graphs, spectrums and raw data into our reports.
Although sometimes a little cumbersome, we are able to design reports where the end result is a nice clean
report that effectively communicates our recommendations as well as the data our conclusions are based
on. The following shows a portion of a report from the Odyssey vibration analysis software. As you can
see, it has been pasted into Excel and Word.
In some cases we are able to link these reports back to the PdM software packages through a
process called ActiveX. This process creates a link from the PdM software package back to the actual
report. This function can be very useful for large PdM departments. It gives an analyst or manager ready
access to reports written by other analysts or managers.
You have probably all used a method similar to the ones mentioned above for your own custom
reports. The next thing I would like to discuss may be something you have not seen before. It is the
capabilities of reports using what is called dynamic data exchange.
Enteract Home
Dynamic Data Exchange
Dynamic data exchange, or DDE, is the term given to the functionality where two different
software packages can both send and receive data from the same database. Commonly for reporting
purposes however, DDE will be set up as a read only link for the reporting software. Imagine having a
custom designed report in Microsoft Excel that is linked to your vibration database and automatically
shows the latest data every time you open it. Wouldn’t such a capability be quite useful?
The example below shows a piece of an Excel spreadsheet that has been linked to a PdM database.
From the outward appearance there is no way to tell that it is anything other than a normal spreadsheet.
The example above is only a small part of the information that can be pulled out of a database.
This example also is for only one technology. A report such as this can easily have many different
technologies included.
There are numerous advantages to having a report with the capability of dynamic data exchange.
For the analyst, they are able to use the report to target only those machines that are in a critical level. With
this capability they are able to increase efficiency by eliminating the need to spend time generating reports
and analyzing machines that are operating normally. For the people in management, they are able to pull
up the status of the machines without the need to ask the analyst or wait for reports. Maintenance
technicians can use such a report to monitor the effectiveness of the repairs they made. Warehouse
personnel can use the report to plan for advance ordering of machine critical parts. Production engineers
and technicians can use the report to monitor the effects of changes in the process on equipment and to plan
their production levels based on the condition of the equipment. There are many possibilities for the use of
a report with dynamic data exchange. It is true that PdM programs vary from facility to facility, but a
linked report will always be as good as the program it is linked to. The report just gives a better way to
communicate the information.
Now that I have described a linked report in Excel, why not move on to a report that doesn’t look
like a spreadsheet. A report that has custom pages and visual basic buttons and actions could be even more
useful than a spreadsheet.
The next type of report is similar to the spreadsheet in the fact that it uses links and queries to
obtain information. When you look at it however, you will find that it looks nothing like a spreadsheet.
This type of report I like to call an interactive report package. These types of reports offer many more
functions as well as making more of a user-friendly environment. An interactive report package such as
this not only allows for more customization of views, but it also has the capability of allowing the user to
enter comments and analysis notes that will be stored as part of the information for that machine. The
following picture is a copy of a page from an interactive report package. You can see that this example
includes multiple technologies.
P R E DIC TIVE
M AINTENAN CE
Many PdM programs use this approach to multiple technologies and are very effective. This may
be due to the fact that different groups of people are handling the different technologies. The disadvantage
to this type of system is that there is a separate report for each technology. This makes assessment of a
machine more cumbersome. Even if the technologies are all separate, the reporting can tie them all
together. This leads to the approach described by the next figure. Please note that this is only an example,
and that the actual configuration of the software packages and databases may vary. In the end, you have
one comprehensive report as opposed to a number of partial assessments.
P RE DICTIVE
M AINTENAN CE
INTERAC TIVE
M ULTI-TEC HNO LOGY
RE P ORT P AC KAGE
O IL ANALYS IS N DT DATA
D ATA
O P E R ATIO NS
TE C H N ITIO NS
You can see by the layout above that the interactive report can give users all the access they need
without the need for access directly to the data. The PdM department, the interactive report package, and
the database server can all be interconnected.
When developing a custom report package there are a number of things to consider. First you
should put some thought into making the screens and buttons as easy to use as possible. You will also need
to consider who will be using the report. Will they want to see all the information or just parts of it?
Managers, for example, may just want to see graphs and charts showing the numbers for the entire facility.
In that case consider using something similar to the bar graph on the following page. It clearly conveys the
information for the entire facility.
This screen also has a button that says “Add Notes”. This feature is for the analysts and managers
that may want to add notes for this machine. In some cases these notes can be written back to the main
database, if not they can be stored locally within the reporting program.
When considering developing any type of multiple technology custom report package, a certain
amount of thought must be put into the setup of the databases for each of the software packages. For
example, you will need to have a common link between all of the databases. This is true even if these
databases are of different formats. I would suggest using the machine number as the common link. Many
electrical and instrumentation departments prefer to think of equipment by the MCC ID number. Since
many PdM programs utilize electricians for IR and MCE data acquisition, this naming convention will have
to be addressed at the start of the program. For existing programs, some software packages will allow you
to insert an alternate name in a second field or comment section. The bottom line is, if you do not have a
common link between the databases it is very hard to pull the different technologies together.
Database table structure is another topic that must be considered. A complex database may have
as many as two hundred tables. For reporting purposes, you will probably need information from only a
few of the tables. Finding out which tables you will need can be the challenge. This is where having
extensive knowledge of your software packages will be useful. As I said earlier, you may need to contact
your software vendor and ask for the information.
As with any custom report packages, you should always obtain as much user input as possible.
Different facilities and different departments have different preferences and requirements. One
recommendation would be to make a list of all the properties wanted by the users and start picking the easy
and important ones first. Then weed out the requests that are too complicated or beyond the scope of the
report. The list of items that you have left should give you a good solid foundation to start with. Once you
have the report up and running you can add more features as needed.
A network installation is the obvious choice for a custom report package. This will allow multiple
users to access the report from their clients. The main report should be stored at some central location,
such as the server. Use password protections to control access to the report, and keep the report itself set to
read only.
In conclusion I would like to say that the use of custom report packages has definitely enhanced
the productivity of the predictive maintenance department that I work in. I usually save a copy at the end
of each month, and everyone involved looks forward to the report. A few select people have the linked
access to the report, and that seems to work well. We use the report to watch the critical level machines
closely and adjust the frequency of data collection on machines based on their status. All of these custom
report packages that I have installed have been a success and I would encourage anyone who has the desire
to better their program to implement a custom report of their own.