Find out more about cViewBATCH

Advice on report vs. data

The typical report is, in essence, a data query with nice formatting. This leaves a tremendous amount of value unrealized. If you're the report developer or administrator, putting out these kinds of reports makes you far less valuable to your company than you could be. And during staff cutbacks, that's personally important. Adding irony to the situation, staff cutback decisions are typically made by Excel spreadsheet--which is why those cutbacks often don't make sense. They aren't made based on business intelligence but on rudimentary analysis of partial data.

You need to ensure your reports contain business information, not business data. They need to be decision tools, not intermediary data sources. Your goal with your reports should be to provide managers with insight that helps them make sound business decisions. Ask them what questions they need answered, and see if you can provide those answers with your reports.

Security tips

• Define the report distribution parameters, as laid out in our article on that subject.
• Control passwords strictly, and educate end-users on the password policy. Stress to them that writing passwords on the bottom of coffee cups, making passwords all alpha, and taking other careless measures with them can cost the company some jobs. Some experts suggest it is a good idea to set passwords to expire every X days. End-users really hate this, and the practice results in their writing passwords down where they can find them rather than have to remember a new one every week or so. Consider the actual consequences of such a policy, rather than its intentions.
• Educate end-users to log out of their reporting sessions if they leave their workstations. This is a security measure, and it is also a way of conserving license seats when a licensing arrangement calls for a limited number of seats. You can get around this licensing issue by purchasing an unlimited license of cView.
• Educate end-users to clear out their caches and temporary folders after viewing sensitive files. If this step seems a bit like spitting into the wind, your network admin can set up the system so those folders reside on a central, controlled server or are deleted at logout. It is also possible to have those folders checked and purged at boot-up.
• Educate end-users not to print out their reports unless doing so is absolutely necessary. Paper reports are a huge security risk.
• Educate end-users to shred any and all paper reports they are done with, and to lock up any paper reports they leave unattended.
• Put a security disclaimer on reports that have especially sensitive information. Ask your operations manager for instructions on what text is appropriate.
• Develop a concise written security policy, get it approved by your operations manager, and distribute it to all end-users.
• Do random security checks. The idea isn't to "bust" violators, but to identify and correct problems. Submit a detailed report of these checks to your operations manager, including both absolute and relative data (number and kinds of violations, and the trends), plus a short assessment of the severity and specific risks. Your operations manager may ask you to step up training or to "turn in" violators. 
  

• If your product isn't in the support area, then the support history on it is so thin that a support plan hasn't been required.
• If your product is in the support area, that doesn't mean it's troublesome. Only that an inordinate amount of effort has gone into supporting a very small percentage of customers using that product.

Each developer has separate pricing, delivery, scope, and conditions for support. Our support plans area helps you quickly see what support plans are available from specific developers or for specific product lines.