Incident tracking

[SecTrainer]

Spyyman:
Tout the ROI aspects of power conditioning and UPS.

Right. ...and don't use an outlet that's on a wall switch that the janitor will come in and turn off as one of our branch managers inadvertently did once! Every morning we got the same complaint about the system going down around 2 AM, sometimes interrupting the data dump from the branch. There was no other evidence of power failure at the branch (clocks stopped, etc.). We dinked around remotely diagnosing the system until I finally had to travel the 80 miles to the branch and sit in the office one night in order to figure out what was happening!

Turns out the janitor had initially yanked the cord on the server power strip out of the wall one night when he was sweeping, and then plugged it back into the wrong outlet nearby - one that was controlled by the wall switch. If he'd plugged it into the right one, we'd only have had the outage that one night. As it was, every morning when he left he very faithfully and religiously crashed the system for us as he turned out the lights.

Oh well, at least it was easy overtime for me when I'd been dreading possibly having to tear into or replace the server. None of us had any idea that any of the outlets were on the wall switch circuit, but it seemed kinda dumb we didn't think of that possibility.

[N. A. Corbier]

Maybe he doesn't need a "Rolls-Royce" system when a "Chevy" will do.

This is a simple Visual Basic or VB for Access program written by two people. Neither are most likely professionals...

That said, there's no reason to deploy a huge RMS system requiring the infrastructure behind it when a simple Access database (even though I loathe Access) will do.

Keep in mind, I'm one of those open source guys.

[SecTrainer]

I think that some might have the misconception that you should only do needs analysis and approach the implementation with a "project" mindset when you're looking for the "Rolls Royce" class of software or "an enormous RMS system". Nothing could be further from the truth...you do it whenever you buy software - "big" or "small" - that will be used to implement important business processes, as incident tracking most certainly is for any of us. This is like picking out a company vehicle by throwing darts at the newspaper ads. After all, they all have an engine, four wheels, seats and a steering wheel, don't they?

Needs analysis is nothing more than figuring out what you need the application to do. It can be done, if there's some kind of all-fired rush here, in as little as a day or less of brain-storming. I fail to see how anyone can justify buying anything having to do with business information systems, even something as trivial as a modem, without at least knowing exactly what it needs to do, what features it should have and, if applicable, what known standards it must meet...to say nothing of not having a good handle on the range of products available and even what "extra" features some might have for the same price as some others.

And, I have to say that anyone should be enormously skeptical of any commercial product when the "home page" for that product is sitting at an URL like "www.fastwilly.com/betty/TickleMeElmo/BigBird"...and when the price of the product that clearly proclaims what the people selling it think about the product themselves, which isn't much! I'm not saying that there isn't a lot of OVERpriced software out there because there is, but I'm even more suspicious of low-ball prices when it comes to software that I'm going to run in my business.

...and there's always this idea: If you're just going to implement a solution that's little more than a simple Access database or Excel spreadsheet, there are a lot of people out there who will happily create a custom "application" just for your company that will suit your needs even better for not that much money...and you'll have someone to scream at if something goes wrong. IRINDEX itself doesn't look like it could have taken much more than a couple of weeks of "programming", given all the "wizards" that are available in the Office products. In Access, once you've defined the data tables, their relationships and the basic queries (which doesn't take long even for projects involving a couple of dozen tables) everything else like creating input/output forms and reports is like falling off a log, so to speak.

I'm a VBA chunker myself just for quick-and-dirty apps. I created an Access-based transcription-tracking application, "TransTrak" (clever, eh?) for a small 80-bed psychiatric hospital in California that had been losing their paper documents all the time. (I did take about a week to determine the specs even for this little application.) Well, when I showed it to them, THEY all thought it was a miracle - the best thing since bibs for babies - but I knew it really wasn't any such thing. If they had needed much more horsepower, or a secure networked app, TransTrak wouldn't have made the grade. Since they had assured me that there were no plans even on the distant horizon to grow larger than they were, it was just enough for their needs, as I was very careful to tell them.

What's important to know about this story is that even though I created all kinds of snazzy reports and forms in the application (about 20, I think), there were reports that I hadn't thought of that the hospital decided they needed, and when they came back to me with a list of about 10 more it took me just one morning to create them all, because you already have the foundation defined. All you have to do is (maybe) set up new table relationships, create the query behind each report or form, and then generate the report or form itself based on that query.

This further customized their "product" and made them even happier with it. It was also customized because all the reports included their logo, their privacy statements, etc. This is the real value of just having someone do it for you if your needs are reasonably lightweight.

I was charging $75/hr for simple Office apps at that time, and I think that TransTrak itself, including 2 hours of training for the staff and a 20-page user's "manual" that I printed up, wound up costing the hospital around $2200, including the mods. I billed out the consultation separately because it was dealing with many other IT issues. So, if it's a difference of between, say, $200 for someone else's idea of the application and maybe a $couple grand or so for a custom design that specifically fits your own needs, why not roll your own? You'll be happier with it, I'd almost guarantee.

[Bill Warnock]

Explaining needs analysis to bean counters and those wearing green eyeshades is like collecting a basket of rooster eggs. They can't see beyond their own little world and unfortunately, their boss and your boss are in two diffrent directorates. The language is not common and if anything goes haywire, it's your fault even though you were never consulted about the equipment that suddenly arrives at the door and has no earthly correlation to your needs analysis. Then this person can tell his boss how much money he saved by not buying that frivolous thing "those security types" wanted to spend.
When the system goes bust and your boss has to report why, the procurement types suddenly disappear.
Enjoy the day,
Bill

[Mr. Security]

Right. ...and don't use an outlet that's on a wall switch that the janitor will come in and turn off as one of our branch managers inadvertently did once! Every morning we got the same complaint about the system going down around 2 AM, sometimes interrupting the data dump from the branch. There was no other evidence of power failure at the branch (clocks stopped, etc.). We dinked around remotely diagnosing the system until I finally had to travel the 80 miles to the branch and sit in the office one night in order to figure out what was happening!

Turns out the janitor had initially yanked the cord on the server power strip out of the wall one night when he was sweeping, and then plugged it back into the wrong outlet nearby - one that was controlled by the wall switch. If he'd plugged it into the right one, we'd only have had the outage that one night. As it was, every morning when he left he very faithfully and religiously crashed the system for us as he turned out the lights.

Oh well, at least it was easy overtime for me when I'd been dreading possibly having to tear into or replace the server. None of us had any idea that any of the outlets were on the wall switch circuit, but it seemed kinda dumb we didn't think of that possibility.

At least it wasn't the guard this time.

[davis002]

I would suggest taking a look at ReportExec. http://www.report-software.com

• Case Reporting
• Field Interview Reporting
• Case Manager
• Daily Event Log
• Computer Aided Dispatch (CAD)
• Citations and Warnings Module
• BOLO Screen with Digital Imaging
• Officer Training and Tracking
• Master Name Search
• Property Manager
• Photo Lineups Module
• Vehicle History Tracking
• Arrest and Booking Module
• Parking Permit
• Daily/Monthly/Yearly/Custom Statistics
• Separate Alarm, Damage, Fire, Injury, and Theft Reporting Screens
• Lost & Found Property Tracking
• Instant Contact Reports and Histories

I suggest going to the site, download the demo, and give it a test drive. If you have any questions or want to see an example case report, tow report, etc. Feel free to private message me.

[SecTrainer]

I would suggest taking a look at ReportExec. [URL=http://www.report-software.com]http://www.report-software.com[/URL...(feature list omitted from quote)...I suggest going to the site, download the demo, and give it a test drive. If you have any questions or want to see an example case report, tow report, etc. Feel free to private message me.

This is much more along the lines of what I would expect to see in a professional-grade product...or, actually, products (there are several here). As with many others of this grade, the pricing is based on "licenses", whether "users" or "concurrent users", and requires careful consideration.

"Concurrent users" presents a question not unlike telephone queuing theory, which tries to identify how many people will typically be using the phone system simultaneously. In looking at this issue, phone engineers have developed a notion called "the busy hour", meaning the time of peak demand. It is this "busy hour" traffic that drives the decision about what minimum facilities (trunks, switches, etc.) are required to serve "x" number of users. You can use a similar approach - not formally, of course, but just in a "down-and-dirty" way - by basing the licenses you need based on how many concurrent users you're likely to want to have "online" at the busiest time of the day.

This seems to be a good example of the kind of software that you'd be more comfortable basing your business processes on, compared to some of the others that have been mentioned.

[Squidly]

A lot of interesting points in here!!
Sectrainer we are using an access database system which was created inhouse. In prinicpal it works ok but as stating in in of the posts it is not fool/idiot proof.
With our system I do the majority of the data interpreting and the biggest problem that I have is that there is no failsafe measures for the person filing the report to skip things like a simple droptab. Without a correctly filled out report you lose key information for stats.
Another point is the legality of the data/report in a court of law. I know with our DB the information could be changed at a later date. There are other systems that this could be done also. When looking at reporting systems there needs to be fool proof reports, such as if a field is blank it alerts you, when you hit save that is the end of the matter and it can not be tampered with at a later date etc.
The system we have is ok but obsolete fields can not be deleted such as old staff etc. if you delete it you lose the information in the old reports.
Agreed I hate access but I have a resonable knowledge of the system. But I still havent worked out how to overcome these problems!! Anyone??

[SecTrainer]

Another point is the legality of the data/report in a court of law. I know with our DB the information could be changed at a later date. There are other systems that this could be done also. When looking at reporting systems there needs to be fool proof reports, such as if a field is blank it alerts you, when you hit save that is the end of the matter and it can not be tampered with at a later date etc.
The system we have is ok but obsolete fields can not be deleted such as old staff etc. if you delete it you lose the information in the old reports.
Agreed I hate access but I have a resonable knowledge of the system. But I still havent worked out how to overcome these problems!! Anyone??

A few suggestions, if I might:

1. Presuming that your data (reports, etc.) are being accessed by bound forms, you would set the "AllowEdits", "AllowDeletions" and "AllowAdditions" properties of the data retrieval form(s) all to NO. You can do this via the form's property sheet, or by way of a macro or Visual Basic.

As a matter of good DB practice, always use separate forms for data entry (and report creation) and data retrieval. In other words, a data entry form would never access existing records anyway, and would have at least the "AllowAdditions" and "AllowEdits" properties set to "YES" rather than "NO". You can think about whether you want "AllowDeletions" set to "YES" or "NO".

The data retrieval forms are the ones that would have the properties set to "NO" as noted above. All the user can do with such forms is to view/print data; they cannot change it.

2. You probably would not like a database that allowed NO editing via forms. You can create data editing forms that will only function on entry of the password of certain users like supervisors, as well.

3. There are a number of ways to verify that fields in a data entry form have not been skipped (do not have empty values), as well as to make sure that the values entered are of a certain type, format and range. These are discussed under topics like "data verification", etc. in most decent Access books and most are quite easily implemented.

Some methods of data verification are established at the time of table design, but can be changed afterward. Others involve the data entry forms, forcing the user to move through the form in stepwise fashion and preventing them from leaving a field until there is some "change" (or entry) to the field.

4. Finally, assuming that at least some limited editing capabilities are desirable, there are ways to audit, or track, such changes to Access records. With audit capabilities, it is then sufficient (and better) to be able to testify that the audit trail shows that the report has not been changed, or how it was changed. "Yes, the record was updated on 5/15/2006 to correct the subject's date of birth. There have been no other changes to the record." This kind of testimony will NOT invalidate the legality of a report, but rather would tend to corroborate it because no one will ever believe that there is ABSOLUTELY no way to ever change data in a database and opposing council would have a field day if that's the approach you try to take. Better to say "Well, yes...of course you can change certain aspects of our records, but we know about it when a change is made, what the change was, who made it and when because we have an audit trail."

Building audit features into your database, even an existing one, can be done fairly easily, but it does require a modest ability with VBA. You could build your main application yourself using basic skills, and then "job out" programming the auditing function of the database. It's not a major project. Basically, it amounts to the creation of a table that uses a fairly simple routine to track changes "behind the scenes", while also recording the user, date and time of the change. The user is unaware this is going on.

Since such audit tables can grow very large, the auditing routine will need to incorporate some maintenance elements, such as the ability to "dump" to a compressed file, removable media, etc.

Of course, if you add audit capabilities to an existing DB, it will only be able to say what happens to your records going forward, not what's happened to any records before it was implemented.

Hope this helps!

[Squidly]

Thanks Sectrainer... I will take a look and see what we can do!!
Shale keep you posted!!

[FireEMSPolice]

We use E911 made by Rad Software. Its a worthless program.

[N. A. Corbier]

Oh, man. I looked at that stuff, and was like, "Wow, that crash course in Visual Basic 3.0 paid off!" That they charge $400 dollars for a souped up Visual Basic for Applications or Visual Basic program amuses me greatly.

[FireEMSPolice]

Oh, man. I looked at that stuff, and was like, "Wow, that crash course in Visual Basic 3.0 paid off!" That they charge $400 dollars for a souped up Visual Basic for Applications or Visual Basic program amuses me greatly.

What are you talking bout?

Davis002, you have a PM!

[Arff312]

I just got my company to tUpgrade to E911 Pro. We used to and still do have paper logs (until the E911 Pro is phased in completly). I figured that atleast 911 pro would be better then nothing. I mean i was watching disptach one nght flip through papers to get info. So it is a start to have E911 Pro. We still have some people who dont like it. But there is only one or two of them now of our 70 person staff. It is not as good as 10 000 dollar systems but for what you pay for and our needs it works fine.

[FireEMSPolice]

I just got my company to tUpgrade to E911 Pro. We used to and still do have paper logs (until the E911 Pro is phased in completly). I figured that atleast 911 pro would be better then nothing. I mean i was watching disptach one nght flip through papers to get info. So it is a start to have E911 Pro. We still have some people who dont like it. But there is only one or two of them now of our 70 person staff. It is not as good as 10 000 dollar systems but for what you pay for and our needs it works fine.

Let me know how it works. Ours sucks. Always crashes.