Computer question/idea

[Airedale]

I run a medium sized industrial plastic recycling plant. Our material processing is pretty efficient but our material inprocessing is not.

We currently unload trucks then weigh, pen and paper the weights, and place the material. The hand written reports come to me. I compile and input the data into our reports and forward to the office manager. We use both Word and Excel for reports.

This is the scrap business. Barcodes or anything additional on the supplier end is a no go.

My idea:

Have something like an Ipad or Motorola Xoom on the dock truck.

-New load arrives

-Dock guy pulls up the report template for that particular supplier

-As dock guy unloads, (for example)he picks up a box, he taps the listing for that material type,looks at his scale readout and enters the weight. He would do this 20-50 times per load.

-the program would need to handle multiple entries for the same type material and provide a cumulative value by type of material

-upon completion, dock guy would email me the report

Is this possible?

I am not tech savvy but think the idea would save time.

Thanks,

Dave

Edited January 7, 2011 by Airedale

[Graham Smith]

PM sent

[Classic_jon]

Part of my job duties is as a project designer and to help design secure user interfaces and the business processes that go with them so, my answer here will be fairly complete system answer. The only way to make something like what you are talking about work *properly* is to develop a "complete system" and the business processes that go with it. This is including reporting capability for tracking purposes. Everyone always seems to forget about the reports until the very end! Oddly enough, if you figure out what you need on the reports some of the other parts of the program almost write themselves...

I would say it was possible two different ways depending on what you have available, and what types of things you are dealing with, you could theoretically go either way.

1) Mobility method.

If you need to be mobile, there are several Palm based ruggedized devices that allow data entry for what you are talking about. Like this one: http://www.nextag.com/Janam-Technologies-XP20-Batch-696169445/prices-html

You will need a programmer/developer that is knowledgeable enough to write the applications front and back ends and the wireless communication equipment for it to communicate to the network/database server.

2) Stationary method:

If the person doing the data entry will generally be in one spot AND you have a fairly protected place to put it you could use a regular PC to do the data entry. Just make sure to get a ruggedized keyboard and a power supply that has a filter if there will be a lot of dust in the air.

Your total cost either way for the hardware will be fairly similar BUT if you go with the mobile method you will need a bit more development time AND you will really want multiple data entry devices on hand in case one of them breaks or runs out of power, etc....because the last thing you need is to have the system break because you didn't charge the batteries....

I have built several systems that are used in shops and other dusty or greasy environments and you NEED them to be ruggedized and protected from dust, dirt, and grime or you will spend more time buying new parts than you will ever expect. Spend the money on it *now* to do it right the first time and you will avoid a lot of issues where things stop because a key on the keyboard quits working.... In other words, if you are going to do this, don't cheap out on the parts OR on the quality of the programmer that writes the app!

Overall the most expensive and time consuming part will be the software development. Take your time and get the guys that do the data entry involved in designing the data entry interface. Too many companies just tell the programmer to "go and write something" without getting the people who will actually USE it involved. What the programmer THINKS they need is 80% of the time not what they REALLY need. You will be surprised at how much time, effort, and worker complaints this simple thing will resolve. It takes more time up front to do it that way but in the end you spend a lot less time tweaking and making changes later...so again, do it right the first time and save yourself $$ and headaches later.

I can not stress enough on things like this to do them right the first time, it will save you soooooo many headaches and a LOT of $$ in project overruns and redesign!

Edited January 7, 2011 by Classic_jon

[D.Hayden]

Just my .02.. if you do it, don't write to a particular device.. do it with a web interface to a web server. Keep the device dumb (meaning the whole application is on the server.. one point to backup and secure)

Almost everything these days can run it.. and you're not stuck on something proprietary. Then you can use an iPad, iPhone, Kindle, PC, whatever.

And it wouldn't have to be email, like Jon said, you'd just get the reports from the server, or emailing it as well is a few lines of code.

Probably the hardest thing you have to overcome is if the guys will actually use it. Get them involved upfront, so they have some ownership.

The code itself is trivial.. Jon's post will point you in the right direction..

[Classic_jon]

Just my .02.. if you do it, don't write to a particular device.. do it with a web interface to a web server. Keep the device dumb (meaning the whole application is on the server.. one point to backup and secure)

Almost everything these days can run it.. and you're not stuck on something proprietary. Then you can use an iPad, iPhone, Kindle, PC, whatever.

And it wouldn't have to be email, like Jon said, you'd just get the reports from the server, or emailing it as well is a few lines of code.

Probably the hardest thing you have to overcome is if the guys will actually use it. Get them involved upfront, so they have some ownership.

The code itself is trivial.. Jon's post will point you in the right direction..

Exactly!

The system needs to be "self contained" and handle 99% of the needs of it's task(s) in the system. If done correctly, there is no need for e-mail, or excel etc. Honestly, way to many companies and people use Excel and other spreadsheet software to to a lot of things that a good program should handle internally. Using a spreadsheet as the primary means of tracking and handling important data, In my opinion, is a disaster looking for a place to happen!!

Having the program do it is good for multiple reasons. Some of the best reasons are 1) Valid Backups of the data. 2) Data integrity and 3) availability of the information. on 1) having a *valid and up to date* backup of important data is ALWAYS easier if you store the data in one spot, on one server and let the backups run on it on an unattended schedule in the middle of the night. If you have important data spread around all over the place, if one persons desktop goes down or they "forget to make a backup" and you lose the data...you are just stuck. On 2) Data integrity: If the data is in a spreadsheet and Jo-jim-bob accidentally opens the spreadsheet and alters some data... you have NO WAY of telling who did that...or IF they did that until it is too late and you have to go find out where the error is, which is a real pain as I am sure you know. If the access to the data is controlled by a program and all they can do is VIEW it without clicking an edit button, then you can track who did what to the data and it also can not be "accidentally" altered. on 3) availability of data. If you use a program that is web based then ANYONE with the proper permissions can view it without having to go and get the latest spreadsheet. This is good so that you don't have to e-mail things around and risking people altering things, or in a worst case scenario, it being e-mailed out by accident to someone that should not have that data.

Now, all that being said, having a way to export that data into excel is not a bad idea, BUT if the software is written properly, Excel would be used as a last resort to "check things" and play the "what if this happened" game to it and not as the primary means of handling the data.

Trust me, from first hand experience at several companies (one of them a Bank )...using Excel files, or e-mailing Excel files around is insecure, time consuming, and inefficient manner of doing things...not to mention possibly error prone if someone presses a wrong key and saves it. Get the software written correctly to do everything all in one package and it will pay for itself in efficiency very rapidly.

As an example, At the last company I worked for I had a programmer spend a week with a Data entry person designing the user interface and re-write the program they used to do their job. They went from starting at 6:00 AM in the morning and finishing the task at 3:00PM to starting at 6:00 AM and finishing at 11:00 AM.... we cut almost *4 hours* off the task just by making it more efficient to enter the data and providing them with proper reporting capabilities. The re-write paid for itself in less than 2 months....

[Airedale]

Thanks for all the input.

Thanks to Graham for talking with me today. He gave me great input.

This project will happen.

Dave

[Flexmoney]

I'd suggest keeping it VERY task specific. The more "versitile" it is, the more complicated it becomes to the end user.

As mentioned... involvement = commitment ...get the end users in on it from the start.

[Erik S.]

Suprised no-one has mentioned utilizing SQL database. With a simple web-type front-end, SQL databases can be VERY powerful and secure since all the data is stored on a server that could be locked up in a secure location somewhere. The only way to access it is with username and password and only accessible from within your company. If you had to work from home, you could arrange that with some configuration mods, but all SQL data could be exported as Excel file and you could do with it what you will.

There is obviously alot more to it than this, but the jist of it: secure, reliable, user-friendly.

[D.Hayden]

With a web server.. I'd guess 99% of all developers would use SQL.. so I figured it was a given

[Erik S.]

Sorry, my fault for not reading all the posts thoroughly.

[Classic_jon]

With a web server.. I'd guess 99% of all developers would use SQL.. so I figured it was a given

Same here and why I said: "You will need a programmer/developer that is knowledgeable enough to write the applications front and back ends and the wireless communication equipment for it to communicate to the **network/database server."** in my fist post.

No worries though, better to mention it twice than to have it missed.

Edited January 12, 2011 by Classic_jon

[D.Hayden]

lol.. I do everything with webservers and SQL.. the only question for me is a) same machine or seperate... I do take these things for granted.

[Erik S.]

with virtualization now days, you CAN have it on the same physical machine and just 2 virtuals with separate IP's. Doesn't help you with the hardware redundancy, though....just depends on the fault tolerance the company needs.

[Classic_jon]

with virtualization now days, you CAN have it on the same physical machine and just 2 virtuals with separate IP's. Doesn't help you with the hardware redundancy, though....just depends on the fault tolerance the company needs.

I dunno, there are some pretty impressive blade servers, clusters, and hot swappable servers out there these days... the question though is how much $$ does your company want to spend.

I have seen more than one CEO want all kinds of "goodies" until they get the price quote back...and they generally have this series of expressions.

[Airedale]

Here's where we are in this plan-so far.

We have a server on site. We are going to run WiFi capability to the dock area.

We are meeting with the fork scale pimp tomorrow. The (Avery Weigh-Tronix) propaganda claims the ability to enter data into saved templates and then transmit the report to the server. The scale instrument (FLI 425) uses Windows CE.Net platform.

We can then harvest these reports from the server.

We aren't locked into anything at this point.

This is an interesting project.

Thanks for all the input.

Dave

[Classic_jon]

Here's where we are in this plan-so far.

We have a server on site. We are going to run WiFi capability to the dock area.

We are meeting with the fork scale pimp tomorrow. The (Avery Weigh-Tronix) propaganda claims the ability to enter data into saved templates and then transmit the report to the server. The scale instrument (FLI 425) uses Windows CE.Net platform.

We can then harvest these reports from the server.

We aren't locked into anything at this point.

This is an interesting project.

Thanks for all the input.

Dave

Glad to hear it!

Since the Scale uses windows CE.NET that should speed development time up quite a bit but make sure that the server and the Developer are both using the most up to date version of the .NET platform. The latest version of Visual Studio .NET has a *lot* of features that automate many of the more mundane programming tasks, especially in error checking.

Good luck and make sure you have a good and valid backup plan. You may never need it, but when you do need it, it will save you a lot of time and money in lost productivity and historical data. Never underestimate the value of a good backup system, it is cheap insurance!