Think, re-think, think ahead- OUT THINK

Dfigtree

Well-Known Member
As I see the old guard retiring, I see the mainframe jockeys heading out to pasture. However, when last I worked at UPS, the new guard was pouring in. I never skateboarded. I never roller bladed, I never snowbowarded.

The men and women who are running the UPS show today may be a little more advanced than I was, but they represent the old guard going out to pasture. Golfer Scott will be gone in 5 years.

I believe that the "young kids" are the ones who truly know where UPS should be headed. Here's my challenge. All ISers are geniuses. Just ask them.

What would you do to improve the package information process?
What NEW technical, non pakage delivery oriented, businesses should UPS enter, if any?

This is a forum made up of a large number of brilliant individuals. I believe we can OUT-THINK the BOD and Management committee.
 
J

JCL

Guest
Use assets to buy back all class B stock.

Tell WallStreet to take a hike.

Find Jim Casey's original writings. Read them. Be inspired, they are inspiring.

Treat each other with respect.

The will begin to lift. Logic and commonsense will brighten the day.
 

Dfigtree

Well-Known Member
Find Jim Casey's original writings. Read them. Be inspired, they are inspiring.

quote]

Find Jim Casey's original writings.

Now that's an interesting comment. We have seen Casey's sanitized writings but what was contained in his "original writings". And, are they archived anywhere?

BTW, I am serious enough about the young turks having great ideas that I plan to send them to our new CEO under my real name. It will be difficult if the only response to this thread is yours.

D. Harry
 
Here are a few ideas:

Lease out floor/rack space at the state-of-the-art tier IV five 9's compliant data centers.

Lease out unused bandwidth.

Lease out unused storage.

Lease out mainframe processing.
 

Dfigtree

Well-Known Member
Here are a few ideas:

Lease out floor/rack space at the state-of-the-art tier IV five 9's compliant data centers.

Lease out unused bandwidth.

Lease out unused storage.

Lease out mainframe processing.

Good ideas. I personally looked into the last one. Among many other concerns is the liability/backup recovery/disaster recovery concern.
 

Deeohem

Well-Known Member
Package information, but not package delivery... how about package shipping? Right now, there's easily a half-dozen different UPS solutions to ship with (Internet Shipping, Campusship, iShip, WorldShip, Online Tools Harvey?) and they all look and act differently. It's time to merge the code base, add modularity, and extend the software. With AJAX it should be possible to make a web-based software solution that looks and acts more like WorldShip. This should be a goal. As a shipper moves through Internet Shipping, WorldShip, and Campusship, we can offer a consistent look and feel and no productivity loss for our shipper in learning the ins and outs of the various software. Next, if we can get a web-based app that looks like a desktop app, why not replace WordShip with a web-based app? It's be a matter of selecting a robust embedded web-server module and a module to handle offline communication.

Go modular. Build a framework where things like embedded web-servers, MSDE/SQL Express, offline processing, can be linked a compile/install time as necessary.

Improve client-server connectivity. WorldShip currently uses SQL Server in the form of MSDE. I've had shipper ask if they could use their company SQL server. Why not? Why not a flavor of WorldShip, that instead of having a Database module that uses MSDE have one with a generic database comm module? Larger shippers could configure to point to their SQL server and have at. Perhaps other databases?
 

Dfigtree

Well-Known Member
Package information, but not package delivery... how about package shipping? Right now, there's easily a half-dozen different UPS solutions to ship with (Internet Shipping, Campusship, iShip, WorldShip, Online Tools Harvey?) and they all look and act differently. It's time to merge the code base, add modularity, and extend the software. With AJAX it should be possible to make a web-based software solution that looks and acts more like WorldShip. This should be a goal. As a shipper moves through Internet Shipping, WorldShip, and Campusship, we can offer a consistent look and feel and no productivity loss for our shipper in learning the ins and outs of the various software. Next, if we can get a web-based app that looks like a desktop app, why not replace WordShip with a web-based app? It's be a matter of selecting a robust embedded web-server module and a module to handle offline communication.

Go modular. Build a framework where things like embedded web-servers, MSDE/SQL Express, offline processing, can be linked a compile/install time as necessary.

Improve client-server connectivity. WorldShip currently uses SQL Server in the form of MSDE. I've had shipper ask if they could use their company SQL server. Why not? Why not a flavor of WorldShip, that instead of having a Database module that uses MSDE have one with a generic database comm module? Larger shippers could configure to point to their SQL server and have at. Perhaps other databases?

Great stuff. That will be included.

I can identify with the people who have good ideas that have been overlooked. Any more? OUT THINK THE BOX!
 

upscorpis

Well-Known Member
Deeohem,

I'm not sure if you know that the latest version of WS has an AJAX based air freight shipping interface. WS also supports integration with other DBs. It just doesn't allow the user DB to own the WS data. Data is able to read and written from/to external DBs and has been for a long, long time. Have you seen the new integration wizard for the technically challenged users?

All that said, you're on the right track with a lot of your ideas. I'd still be a little hesitant to install/require a web server on a customers' machine, however. Shipping PCs are almost always the lowest class machine in the building. Although hardware is getting cheaper, the OS bloat is more than making up for it. There are also security concerns that could arise from having a local web server running.

My belief is that a hybrid approach is in order. Where high performance is required, local implementation is a must. Infrequently used items should be web based. WS serves a diverse customer base when it comes to shipments/day. Local vs. web needs to be variable to some degree so that each customer's needs can be met. That's where your modular/framework approach comes into play.

If you consider what is in WS today, you can see these ideas are already taking shape. The question is how far will it go.
 
S

snoman

Guest
If you are looking to appeal to the skateboarders and snowboarders...

Internal version of the Brown Cafe with different name - something like Employee Lounge.

Publish portions of the IS standards manual in wiki format instead of PDF so employee Subject Matter Experts can provide updates.

Reconfigure campus / testnet to allow easier use of tools across the 2 networks.

Lighten up the peak exception process for non-package systems.

Internal blogging by all levels.

Allow for easier use/testing of relatively stable open source solutions and products. (such as Firefox)

Thanks for asking!
 

Dfigtree

Well-Known Member
Publish portions of the IS standards manual in wiki format instead of PDF so employee Subject Matter Experts can provide updates.

Publish portions of the IS standards manual in wiki format instead of PDF so employee Subject Matter Experts can provide updates.

I actually submitted a wikipedia change concerning the Rosenberg spy case. You skateboarders might be too young to remember the spy story. Wikipedia stated that the Rosenbergs were convicted of "spying". That was incorrect. They were convicted of being part of a "conspiracy to commit espionage". Legally, the difference is HUGE. My change was accepted. I believe one of the two Rosenberg sons was the "expert" moderator.

Please, I do not want to get off topic. I do not want to argue the Rosenberg case.

OUT THINK.
 
A

an anonymous guest

Guest
All this hi tech stuff may be a little bit beyond me, but I would like UPS to continue to look at, improve, and re-engineer the UPS Store concept. I think there is greater potential there than we realize, especially if we look for ways to optimize such as:

Providing non-UPS personal mailing and office services even beyond what MBE used to do. Especially expanding the UPS/Staples concept. Why have a UPS Store, an MBE and a UPS Staples within a 'crow flies' mile of each other? How do they make money? If the personal services save people drive time, mail processing time, and having to be home for delivery time, that would be worth a premium.

Didn't UPS Telecomm Inc do the bandwidth leasing thing? Remember, Enron tried it too, but too early. Now with all the media on the web, bandwidth is starting to be a business again. Maybe CNBC could post the price of bandwidth next to the oil price someday? More bandwidth used equals less oil and gas used JMHO.

Go UPS!
P71
 

Dfigtree

Well-Known Member
Go UPS!
P71

Good one P71. jimmyV.jpg Support the JimmyV foundation. We have lost too many wonderful coworkers to cancer. The JimmyV Foundation has a short list of corporate sponsors. Interestingly, HOOTERs is one. We can definitely OUT THINK HOOTERs.
jimmyV.jpg
 

feeder53

ADKtrails
I believe that UPS should buy back their public shares first. If you get a corporate raider in and sees the assets, they will exploit the goods.
 

Deeohem

Well-Known Member
Deeohem,

I'm not sure if you know that the latest version of WS has an AJAX based air freight shipping interface. WS also supports integration with other DBs. It just doesn't allow the user DB to own the WS data. Data is able to read and written from/to external DBs and has been for a long, long time. Have you seen the new integration wizard for the technically challenged users?

All that said, you're on the right track with a lot of your ideas. I'd still be a little hesitant to install/require a web server on a customers' machine, however. Shipping PCs are almost always the lowest class machine in the building. Although hardware is getting cheaper, the OS bloat is more than making up for it. There are also security concerns that could arise from having a local web server running.

My belief is that a hybrid approach is in order. Where high performance is required, local implementation is a must. Infrequently used items should be web based. WS serves a diverse customer base when it comes to shipments/day. Local vs. web needs to be variable to some degree so that each customer's needs can be met. That's where your modular/framework approach comes into play.

If you consider what is in WS today, you can see these ideas are already taking shape. The question is how far will it go.

I have seen the airfreight screen in WS10. I guessed that it was a rendered version of a UPS Freight web page. I didn't do much more than look, so didn't discover the feel. Just assumed it was HTML forms.

I am aware that we allow ODBC connectivity. Been supporting import/export on it since the Online Pro days. but we don't allow our data to be on any other DB than WorldShip's own DB. I assume that there's a lot of proprietary information embedded in the UPS database, but there's a lot that we store in easily accessible format (the archives are still basically upsdb.mdb) Why hold on tightly to THAT information? It's pretty much obfuscated anyway. Why not let the shipper's IT department store it on their SQL server if they desire? I believe this is what Great Plains and MAS do. As you mention, the shipping computer is usually a low-end computer, especially in shops that have an IT department. Most of the load in WS is supporting the database. Why not let their server-grade hardware support the database and let the hand-me down in shipping just print the labels?

I bow to your knowledge on putting a web server on the user PC. Perhaps a hybrid approach would be better. I do want to caution you though. A lot of our shippers are still on dial up. Even the ones that aren't do notice the difference between WorldShip and the website. Just prior to the WS10 release I was at a shipper and the clerks hated freight because of the web-based interface. Even WorldShip 9 letting them use their existing address book didn't make them happy. If a rare feature is web-based, it will likely remain a rare feature.

I have looked at the new import wizard. It's nice tool to make importing easier for the unskilled users. I figure it and the new export wizard are both useful tools. I'll still use Create/Edit map because that's what I'm used to. This brings up a question/feature request. The new wizards and the old map builder are both GUI front ends which hide the SQL from the end user. Right now we have a wizard for the unskilled, a tool for the moderately skilled, and (in CrossWare) a propriatary tool for the specially trained. But we're missing a segment, the skilled non-UPSer. There needs to be something in between the GUI tools and Crossware. Is there a movement afoot to allow users to edit SQL? I've been at shippers where the GUI didn't cut it and what would have been a minor tweak in the SQL (was preface the table name in the FROM clause with the db name) required the CrossWare trained technician to work on it.
 

upscorpis

Well-Known Member
The reason not to allow the customer owned DB to be the WS DB is to minimize support issues. It is generally good pratice to protect your operational data store and allow others to use copies of the data for their own purposes. This allows the owner to optimize things based on their needs and protects the operational store from corruption and/or contention. I agree that some customers would be capable of supporting their own DB. You are correct that a large portion of the WS footprint is DB. The problem goes back to the diverse customer base. Imagine allowing this type of thing to the masses. It would be a support nightmare. A more controlled approach might be successful. I'm not sure we're hearing a lot of customers asking for this feature given the accessibility of the data via the methods we've already discussed. I'm not against it per se - I'm just not sure it's a slam dunk decision. A similar discussion would evolve for allowing direct SQL access to the DB.

Based on your comments, I think the new AJAX air freight may be a little different than you might be envisioning. The GUI actually loads on the client on first use so after the first load, the delay is minimized and it becomes very snappy. There are remote calls for processing shipments so those will tend to be slower. If you know about the freight business process, a remote call is required to create a pickup request. There is no way around this.

I agree with your point that freight wasn't deployed optimally the first time in WS. It wasn't gold plated out of the gate. Things will improve in that arena as time passes and we get feedback from customers and folks like yourself.

BTW, I don't mean to pee in your corn flakes so I hope you're not taking it that way. I love discussing this stuff with folks that deal with it daily. Good discussions are a great way to get the synapses firing correctly.
 

Deeohem

Well-Known Member
I agree with your point that freight wasn't deployed optimally the first time in WS. It wasn't gold plated out of the gate. .

It happens with new features and changes. I don't know how much new Freight business we got out of it versus now, but I know that BD is more aggressive about the Freight functionality this year. It may not have been gold-plated, but it succeeded in a more important aspect. It didn't break anything.


BTW, I don't mean to pee in your corn flakes so I hope you're not taking it that way. I love discussing this stuff with folks that deal with it daily. Good discussions are a great way to get the synapses firing correctly.
I don't see you trying to pee in my cornflakes. It's been enjoyable. WorldShip (and integration) is the one app left where I'm allowed to challenge myself and it is (usually) enjoyable. This conversation has been like that except I get to miss out on the dreadful parts. As an added bonus, I know someone in MD is paying attention. I can drop hints :-) [help file needs a section on minimum required fields for importing freight (keyed, batch, etc). Shipment Information table is clunky and should have been split when we added Exchange Collect. Standalone map viewer for support tool ]
 
I have a question about Worldship. Back in the day, we deployed WS on dedicated UPS-owned hardware. It seemed to be such a resource hog that it would only run optimally on a dedicated machine (with nothing else). Of course this was when WS first came out and I am not sure what version it is on now. But anyways, my question is has WS performance improved over the years since now UPS has phased out dedicated UPS-owned hardware and pushed towards customer-owned hardware (and not necessarily dedicated just to WS)?
 
I

I D0N7 C4R3

Guest
The WS folks learned a couple of things the hard way in terms of deploying WS on customer PCs. It's apparent that when deploying WS with MSDE, the developers did not consider the minimum system requirements that MSDE needs. I believe that lesson could have been averted if the CT folks could have consulted the Operations portfolio folks and gotten to lesson or 2 in deploying applications that have high CPU usage i.e. PFT.
All in all the WS product from what I've heard has improved but there's a lot that still needs to be done in areas of testing the product before deployment.
 

Deeohem

Well-Known Member
freeloader, I don't think it's a matter of WorldShip improving in performance as much as it was that the hardware improved a LOT while WorldShip up through 8.0 stayed relatively similar in requirements. The high quality UPS owned hardware that we deployed when WorldShip first came out in 2000 (IBM with 433 MhZ Pentium III and 64 meg of RAM) could still upgrade uo to and through WorldShip version 8 (released 2006) True WorldShip wouldn't install fresh on an NT box or win 9x, by that time, butour shippers could still upgrade to 8.0 I don't think there was a noticeable performance hit between 2.0 and 8.0 We used very similar code, the back end was still plain old MS Access (we did upgrade to Access 2K for the file format 'round about 4.0 I think)

That changed when we switched the code from straight VB to VB.Net and the database back end from Access to MSDE.
 

cwtech

New Member
Right now we have a wizard for the unskilled, a tool for the moderately skilled, and (in CrossWare) a propriatary tool for the specially trained. But we're missing a segment, the skilled non-UPSer. There needs to be something in between the GUI tools and Crossware. Is there a movement afoot to allow users to edit SQL? I've been at shippers where the GUI didn't cut it and what would have been a minor tweak in the SQL (was preface the table name in the FROM clause with the db name) required the CrossWare trained technician to work on it.

Specially trained for CrossWare - not according to those above us !!

even though we are specially trained developers and have seen most CRM packages and a myraid of different data sources, we are accorded nothing more than TSG swapping a label printer, according to the powers that be. This is because if they acknowledge that we are developers our status would have to change.
 
Top