The poster forgot to point you to the ClarkConnect website: http://www.clarkconnect.com/
I've been using ClarkConnect for 3 years and am very satisfied with it.
You are correct; but, only if I don't closely manage my time. When we start a project with the client we educate them ahead of time about 5-4-3, and then each consultant needs to manage their time appropriately.
The times when I do return home on Friday are project crunch times; which happens a couple of times a year, for 2 or 3 weeks at a time. Again, spousal buy-in is key; not to mention personal time management discipline.
Lastly, to ensure that I can work on airplanes when seating is tight, I have a TabletPC; which allows me to function at 75% capacity instead of 0% when the jerk in front of me reclines his seat.
In the consulting industry (which is where I work), many of us regularly work what we call a 5-4-3 schedule: 5 days of work, 4 days at the client site, 3 nights away from home. We fly out on Monday AM, and return on Thursday PM; working Friday from home.
This is very do-able, and needn't impact your family negatively. The trick is to stay in close touch when you're on the road, and to develop a routine. My family's routines are structured around the regular days I am away. I make sure that when I'm home I am really home; which means I don't get out much with my old friends in the neighbourhood... since I'm out during the week with my project team I'm not anxious to get out when I'm home.
One last point: your spouse has to buy into this 100% before you commit to it.
To make a PPS file open in edit mode, rename it back to PPT. The only difference between a PPS file and a PPT file is the name; PowerPoint doesn't save the bits differently simply because the user chose to save as PPS.
I continue to avoid Blackberry and Good devices because they do not properly deal with multipart MIME email. The email RFCs provide for email clients with varying levels of capability, but current mobile email devices (especially the Blackberry) ignore the RFCs and dumb down everything to plain text.
I completely get it that the vendors of these devices are trying to keep bandwidth usage to a minimum, and so only allow their client devices to push plain text bits over the wire; however, that is not a good reason to strip everything back to plain text. In my work environment, we mark up email text and rely upon the receiver using an email client that hasn't been completely neutered.
When Blackberries were first introduced, our wireless networks did not have the capacity to push a large volume of rich text email; however, with 3G networks now actively being rolled out there is no longer any business rationale for imposing this limitation.
On a related note: this is yet another example Microsoft continuing to demonstrate their incompetence. In their pursuit of Blackberry's market share, they should have brought full-featured portable email to market. Instead they only just managed---in Mobile Office 5---to produce a client that marginally outperforms the Blackberry client. Bill Gates needs to stop hiring co-op students and hire real developers who can produce full featuerd software.
The article refers to statements by Microsoft, that MS views the ruling as a victory because all the prior art used in the case was rejected. What prior art was that? Does someone have a pointer?
Or, stop taking WinXP's default of granting every user Administrator privileges and set users to "Restricted" user mode (pretty much the equivenlent of a non-root user on *nix). Mr. Otellini's daughter wouldn't be able to install viruses and spyware if she was running as a restricted user.
Before some/. überdolt marks this post as a troll, consider whether or not you have actual experience doing what I've advocated.
Our family PC runs WinXP. My wife and 4 kids each have restricted user ids (I don't use the machine at all). We *never* have viruses or spyware issues. The problem isn't Windows, it the way people use it. If everybody logged into *nix as root there would be many more problems there too.
Sorry, but you're wrong: on a Windows XP Pro machine M-B won't run in Restricted User mode. I made the mistake of purchasing the package and installing it on my home computer. I then interacted with M-B support and they could offer no solution.
Maybe you have mistaken "the program boots" for "the program functions as intended by the manufacturer." M-B will boot in restricted user mode, but it doesn't work as advertised.
Mavis Beacon will only run if it has Admin rights to your PC; as such, it doesn't make my list of possible candidates for use on the home PC. I don't grant Admin rights to my kids (the ones who need to use a typing tutor).
It's not even that Nobody cares about the "evil" of HTML; HTML email was never evil to begin with. There are senders who choose to send poorly formatted emails (causing incorrect results for the receiver), and there are senders who attempt to cause havoc by embedding nasty constructs in their email, but HTML email itself is not inherently evil.
I agree completely, but feel an example will help everyone understand why the poster is correct.
At the end of the lease an asset has residual value. That residual value is determined when you execute the lease. The benefit of leasing comes when the asset has a high residual value; thus the lease payments can be viewed as a loan of sorts, a loan for the difference between the purchase price and the residual value.
For example, if the purcahse price of a server is $10,000, and its residual value after 3 years is $2,500, then the lease is effectively a loan for $7,500, repaid over 3 years. Thus, if you intend to refresh the server after 3 years, you get use of the server for 3 years for $7,500 (plus interest); whereas a purchase of the device would ential use of the server for 3 years for the cost of $10,000 (plus either interest or "the cost of money") and less what you manage to sell it for.
The potential gain from leasing must then be compared with the overhead associated with maintianing an organisation that tracks down and returns assets ON TIME; since late fees detract from the benefit.
There are also non-traditional reasons for leasing. In a former job my boss introduced the leasing of all servers and desktops, where the lease costs were paid by Corporate IT (instead of each department's budget). This allowed Corporate IT to standardise the hardware configurations, and enforce regular refresh of assets, where old assets did not hang around for extended periods of time consuming software licenses and support.
They get fed up with what you call the "geeky game" because they didn't get into I.T. for the love of it. One should pursue a career because you enjoy what you are doing; never pursue a career/job because some idiot high school guidance counselor tells you that it's good money, or a good profession; only pursue because you want to love your career.
Most women I encounter in I.T. don't have any love for their chosen profession. They simply see it as a means to a paycheque. They made a bad decision.
I love the constant change, the requirement (i.e., not just the opportunity) to learn new things and apply those things on a daily basis. Even though I'm not a hands-on programmer any more, and I spend way too much time in management meetings, the fact that I spend lots of personal time keeping up with technology means that I'm a better I.T. manager and a better mentor for those more junior than I.
I.T. is not for those who don't like to work hard, to think hard, and to constantly learn.
There could be a huge number of different files you need. CAD files, images,...
Before starting, try to determine what the true question is. Were you asked to choose something that is truly vendor neutral, or were you asked to choose corporate standards that will interoperate with your customers and suppliers? The first question is *very* difficult to answer; the second one is easily solved (albeit in a non-Slashdot friendly manner).
I will assume the latter question is the true question, and continue my posting based upon that assumption.
For each major document type, determine who needs to be able to read and edit those documents. This question must be answered for your employees as well as your customers and suppliers. Then, choose a file type that is widely used in that community; which may mean standardising on an older version of a particular application.
For example, in the case of word processed documents, MS Word 97 is a very safe, very widely readable (by other applications) format. Newer versions of MS Word can be configured to only create Word97 files, and many other non-MS applications are able to open and edit Word97 files. So, although Word97 format isn't vendor neutral, it is widely interoperable and makes a good corporate standard.
Here's our family's approach to managing the computer:
the computer is in the family room, where everyone can see what you're doing
no computer access of any kind until you can read or write (this motivated the 3 younger, of 4, children to learn to read by their 5th birthdays)
weekdays, limit game-playing to 30 minutes per day (TV is also limited to 30 minutes per day); weekends, the limit is 60 minutes
no limit on amount of computer time used to do homework, write letters, write computer programs, reserving books at the local public library, or anything else that isn't just pure entertainment
Sure the kids do a bit of IMing during non-entertainment tasks; but as long as they "manage" this diversion we allow it.
The problem with the tester's premise is that he is from the wrong era. These punch lines originate from 20 years ago. In those ancient days of computing, the commands did indeed allow a user to effectively (in the case of UNIX) or completely (in the case of MS-DOS) wipe out their file system.
I speak from personal experience on both OSes; 20 years ago, when both OSes were still young.
A fair test of these punch lines can only be executed on MS-DOS 1.x and on one of the *many* UNIX varients from the mid-1980s.
First the RIAA complained that people ripping CDs and distributing them was putting music stores out of business. Now, in this article, the RIAA trumpets the closure of music stores in the context of Walmart's price pressure on those businesses. Sounds like another excuse to me. Instead of whining about the changes happening to their business model, they should embrace the change and join the rest of us in the 21st century.
Sounds to me like a good time to re-watch JFK and listen to Garrison's closing arguments to the jury---just to remind yourself of what we're dealing with.
Let me add some further background info. to Michel's excellent reply.
As Michel points out, your problem has two solutions: continued internal delivery, or outsourced service delivery. No matter which of the two solutions you choose, there is a base level of work you must continue to perform in enabling your support technicians:
interact with your customers to understand their non-English support requirements
produce native language support scripts for the techs to use with non-English speaking callers (asking techs to translate in real-time while they deliver support will slow them down; although, highly technical material supplied by product development is often only supplied to the call centre in English)
decide upon the level of support you want to offer
work with your management to decide how much money you want to spend
One word about "scripting": what I mean by this is the creation of the information that your support techs use when they interact with your customers. In call centres that use low-end, untrained/poorly-trained labour, the scripts are literally scripts the techs follows; and they frustrate the heck out of educated callers (for many products, a minority of callers). In call centres employing more experienced and educated staff, the script material is less prescriptive to the techs and is a combination of technical material supplied by product development and an FAQ database created by the call centre techs themselves as they work calls with your customers.
Now to the heart of what I wanted to pass along: sourced vs. internally delivered support service. All the background work necessary to enable an internal call centre must be done even when you choose to outsource. Generally, outsourcing is chosen in situations like yours to gain the following advantages:
access to a multilanguage call centre
delivery of extended hours service without locally staffing off-hours
cost variability through pay per call billing (i.e., a high quality product that doesn't generate calls keeps call centre costs down)
potentially lower labour rates (in the call centre) lowers your per-call cost
Any qualified outside service provider will provide the above benefits, but there is a fixed start-up cost associated with externally service delivery that you must account for. By this I mean: while an outside supplier will charge you on a per-call basis, there will be something called the "base fees" that you will pay so that the supplier is able to recover the fixed costs associated with preparing to take the first call from your customers. If call volumes are high enough, a supplier will generally agree to smear the fixed cost across their per-call charge; but you will then face a minimum number of calls you will have to pay for each month (even if no one calls). To be fair, you will have a fixed cost internally too; and that cost needs to be factored into your business decision.
There is one midpoint solution you might consider: using your in-country distributors to supply non-English support. This alternative sits somewhere between internal and external service delivery. I have seen small software companies who provide support resources and extra product price margins to their in-country distributors, in exchange for the suppliers taking native language calls from customers, and then passing difficult problems back to the English-speaking support team in your home office. Again, all the background work still has to be done; it's just the solution implementation that changes. For a small software company, this is often the most cost effective solution.
You're right on the money. The validation of the point you make is NeXT's multiplatform strategy:
NeXTSTEP ran on x86, PPC, 68K, Sparc, and HP-PA hardware
a cross-compiler was used which meant that applications developers only needed to compile once (on only one of the 5 platforms) to produce an application that ran on all 5 types of hardware
NeXTSTEP applications would be compiled on Windows using NeXT's libraries, to create a Windows application; while the application would only run if the user had purchased NeXT's MS Windows environment, this did offer an easy migration strategy
The bottom line on this is that to break Microsoft's dominance you have to break their revenue stream. Making applications run under MS Windows doesn't break that revenue stream. Making OSX run on x86 PC hardware doesn't break MS's revenue stream (as evidenced by Linux).
Apple's best strategy is to stay their course and continue to only sell OSX for Apple's own hardware; where they do this in the context of highly innovative, seamless, user-enabling solutions.
Also worth remembering---in the context of your point---is Apple's own Macintosh Execution Environment (MAE) which ran on HP-UX and other UNIXes: a complete Mac emulation which ran very, very well. Apple's cancellation of that product was a little short-sighted; in my opinion.
Fat binaries, anyone? This already didn't work for NeXT.
If you're referring to the technical strategy (i.e., did fat binaries offer multiplatform portability), you are incorrect. Fat binaries worked very well: compile once on my 68K machine and produce an application that ran on 4 different hardware platforms (5 if you count the unreleased PPC product).
If you're referring to the business strategy, then you are right. The ability to run NeXTSTEP on 4 different hardware platforms didn't save the company the way they had hoped it would.
In 1999--2000, we tried doing what you describe (at the company I work for). We have a large WAN with a couple of hundred sites scattered around the world. We used a commercial product called Asset Insight to do the scanning on UNIX, and we used MS SMS on the PCs. Note, we have a very small number of Macs and it wasn't cost effective to address them in the project scope.
Asset Insight and SMS allowed us to tier the data collectors: large sites consolidated their scans and then forwarded the consolidated data on to the global data collector. This was very necessary to keep network utilisation in a predictive state.
The project's ultimate stumbling block became focused within the PCs and workstations themselves:
The initial scanners were too resource intensive and interfered with normal use of the machine (if they happened to run while the machine was being used).
The scanners were very tricky to write: every application uses a different convention to identify itself and its installed version. Even on Windows machines, where the EXE file format provides fields wherein applications developers can store application names, version, and release information, almost no applications make use of these fields.
We still have the system deployed, but it turned out to be much less useful than we had hoped---plus, it is very labour intensive:
the scanners must be constantly updated and the updated scanners deployed;
the users must be constantly managed: users are forever removing or disabling the scanning tool
Our approach with the data today is to focus on the major applications and OSes in use, and not worry too much about the little things. Our security team watches CERT et al and this provides the software management team with some direction w.r.t. the applications to stay on top of.
Sorry I don't have any software recommendations, but I hope our experience will assist you in your planning.
What you suggest should be trivial but isn't: no one has written any tools to import all Outlook's contact fields into an LDAP database. There are several projects that do a partial job of it, but they all require that the user be very conversant with LDAP. In other words, there do not appear to be any "out of the box" solutions to the problem the poster has posed.
Slashdot Mirror
The poster forgot to point you to the ClarkConnect website: http://www.clarkconnect.com/ I've been using ClarkConnect for 3 years and am very satisfied with it.
You are correct; but, only if I don't closely manage my time. When we start a project with the client we educate them ahead of time about 5-4-3, and then each consultant needs to manage their time appropriately.
The times when I do return home on Friday are project crunch times; which happens a couple of times a year, for 2 or 3 weeks at a time. Again, spousal buy-in is key; not to mention personal time management discipline.
Lastly, to ensure that I can work on airplanes when seating is tight, I have a TabletPC; which allows me to function at 75% capacity instead of 0% when the jerk in front of me reclines his seat.
In the consulting industry (which is where I work), many of us regularly work what we call a 5-4-3 schedule: 5 days of work, 4 days at the client site, 3 nights away from home. We fly out on Monday AM, and return on Thursday PM; working Friday from home.
This is very do-able, and needn't impact your family negatively. The trick is to stay in close touch when you're on the road, and to develop a routine. My family's routines are structured around the regular days I am away. I make sure that when I'm home I am really home; which means I don't get out much with my old friends in the neighbourhood... since I'm out during the week with my project team I'm not anxious to get out when I'm home.
One last point: your spouse has to buy into this 100% before you commit to it.
To add to the previous poster's comments...
To make a PPS file open in edit mode, rename it back to PPT. The only difference between a PPS file and a PPT file is the name; PowerPoint doesn't save the bits differently simply because the user chose to save as PPS.
I continue to avoid Blackberry and Good devices because they do not properly deal with multipart MIME email. The email RFCs provide for email clients with varying levels of capability, but current mobile email devices (especially the Blackberry) ignore the RFCs and dumb down everything to plain text.
I completely get it that the vendors of these devices are trying to keep bandwidth usage to a minimum, and so only allow their client devices to push plain text bits over the wire; however, that is not a good reason to strip everything back to plain text. In my work environment, we mark up email text and rely upon the receiver using an email client that hasn't been completely neutered.
When Blackberries were first introduced, our wireless networks did not have the capacity to push a large volume of rich text email; however, with 3G networks now actively being rolled out there is no longer any business rationale for imposing this limitation.
On a related note: this is yet another example Microsoft continuing to demonstrate their incompetence. In their pursuit of Blackberry's market share, they should have brought full-featured portable email to market. Instead they only just managed---in Mobile Office 5---to produce a client that marginally outperforms the Blackberry client. Bill Gates needs to stop hiring co-op students and hire real developers who can produce full featuerd software.
The article refers to statements by Microsoft, that MS views the ruling as a victory because all the prior art used in the case was rejected. What prior art was that? Does someone have a pointer?
But Google's cache does have a copy.
Or, stop taking WinXP's default of granting every user Administrator privileges and set users to "Restricted" user mode (pretty much the equivenlent of a non-root user on *nix). Mr. Otellini's daughter wouldn't be able to install viruses and spyware if she was running as a restricted user.
/. überdolt marks this post as a troll, consider whether or not you have actual experience doing what I've advocated.
Before some
Our family PC runs WinXP. My wife and 4 kids each have restricted user ids (I don't use the machine at all). We *never* have viruses or spyware issues. The problem isn't Windows, it the way people use it. If everybody logged into *nix as root there would be many more problems there too.
Sorry, but you're wrong: on a Windows XP Pro machine M-B won't run in Restricted User mode. I made the mistake of purchasing the package and installing it on my home computer. I then interacted with M-B support and they could offer no solution.
Maybe you have mistaken "the program boots" for "the program functions as intended by the manufacturer." M-B will boot in restricted user mode, but it doesn't work as advertised.
Mavis Beacon will only run if it has Admin rights to your PC; as such, it doesn't make my list of possible candidates for use on the home PC. I don't grant Admin rights to my kids (the ones who need to use a typing tutor).
Actually, it sounds just like RFC compliant email.
It's not even that Nobody cares about the "evil" of HTML; HTML email was never evil to begin with. There are senders who choose to send poorly formatted emails (causing incorrect results for the receiver), and there are senders who attempt to cause havoc by embedding nasty constructs in their email, but HTML email itself is not inherently evil.
I agree completely, but feel an example will help everyone understand why the poster is correct.
At the end of the lease an asset has residual value. That residual value is determined when you execute the lease. The benefit of leasing comes when the asset has a high residual value; thus the lease payments can be viewed as a loan of sorts, a loan for the difference between the purchase price and the residual value.
For example, if the purcahse price of a server is $10,000, and its residual value after 3 years is $2,500, then the lease is effectively a loan for $7,500, repaid over 3 years. Thus, if you intend to refresh the server after 3 years, you get use of the server for 3 years for $7,500 (plus interest); whereas a purchase of the device would ential use of the server for 3 years for the cost of $10,000 (plus either interest or "the cost of money") and less what you manage to sell it for.
The potential gain from leasing must then be compared with the overhead associated with maintianing an organisation that tracks down and returns assets ON TIME; since late fees detract from the benefit.
There are also non-traditional reasons for leasing. In a former job my boss introduced the leasing of all servers and desktops, where the lease costs were paid by Corporate IT (instead of each department's budget). This allowed Corporate IT to standardise the hardware configurations, and enforce regular refresh of assets, where old assets did not hang around for extended periods of time consuming software licenses and support.
They get fed up with what you call the "geeky game" because they didn't get into I.T. for the love of it. One should pursue a career because you enjoy what you are doing; never pursue a career/job because some idiot high school guidance counselor tells you that it's good money, or a good profession; only pursue because you want to love your career.
Most women I encounter in I.T. don't have any love for their chosen profession. They simply see it as a means to a paycheque. They made a bad decision.
I love the constant change, the requirement (i.e., not just the opportunity) to learn new things and apply those things on a daily basis. Even though I'm not a hands-on programmer any more, and I spend way too much time in management meetings, the fact that I spend lots of personal time keeping up with technology means that I'm a better I.T. manager and a better mentor for those more junior than I.
I.T. is not for those who don't like to work hard, to think hard, and to constantly learn.
There could be a huge number of different files you need. CAD files, images, ...
Before starting, try to determine what the true question is. Were you asked to choose something that is truly vendor neutral, or were you asked to choose corporate standards that will interoperate with your customers and suppliers? The first question is *very* difficult to answer; the second one is easily solved (albeit in a non-Slashdot friendly manner).
I will assume the latter question is the true question, and continue my posting based upon that assumption.
For each major document type, determine who needs to be able to read and edit those documents. This question must be answered for your employees as well as your customers and suppliers. Then, choose a file type that is widely used in that community; which may mean standardising on an older version of a particular application.
For example, in the case of word processed documents, MS Word 97 is a very safe, very widely readable (by other applications) format. Newer versions of MS Word can be configured to only create Word97 files, and many other non-MS applications are able to open and edit Word97 files. So, although Word97 format isn't vendor neutral, it is widely interoperable and makes a good corporate standard.
Here's our family's approach to managing the computer:
Sure the kids do a bit of IMing during non-entertainment tasks; but as long as they "manage" this diversion we allow it.
The problem with the tester's premise is that he is from the wrong era. These punch lines originate from 20 years ago. In those ancient days of computing, the commands did indeed allow a user to effectively (in the case of UNIX) or completely (in the case of MS-DOS) wipe out their file system.
I speak from personal experience on both OSes; 20 years ago, when both OSes were still young.
A fair test of these punch lines can only be executed on MS-DOS 1.x and on one of the *many* UNIX varients from the mid-1980s.
First the RIAA complained that people ripping CDs and distributing them was putting music stores out of business. Now, in this article, the RIAA trumpets the closure of music stores in the context of Walmart's price pressure on those businesses. Sounds like another excuse to me. Instead of whining about the changes happening to their business model, they should embrace the change and join the rest of us in the 21st century.
Sounds to me like a good time to re-watch JFK and listen to Garrison's closing arguments to the jury---just to remind yourself of what we're dealing with.
Let me add some further background info. to Michel's excellent reply.
As Michel points out, your problem has two solutions: continued internal delivery, or outsourced service delivery. No matter which of the two solutions you choose, there is a base level of work you must continue to perform in enabling your support technicians:
One word about "scripting": what I mean by this is the creation of the information that your support techs use when they interact with your customers. In call centres that use low-end, untrained/poorly-trained labour, the scripts are literally scripts the techs follows; and they frustrate the heck out of educated callers (for many products, a minority of callers). In call centres employing more experienced and educated staff, the script material is less prescriptive to the techs and is a combination of technical material supplied by product development and an FAQ database created by the call centre techs themselves as they work calls with your customers.
Now to the heart of what I wanted to pass along: sourced vs. internally delivered support service. All the background work necessary to enable an internal call centre must be done even when you choose to outsource. Generally, outsourcing is chosen in situations like yours to gain the following advantages:
Any qualified outside service provider will provide the above benefits, but there is a fixed start-up cost associated with externally service delivery that you must account for. By this I mean: while an outside supplier will charge you on a per-call basis, there will be something called the "base fees" that you will pay so that the supplier is able to recover the fixed costs associated with preparing to take the first call from your customers. If call volumes are high enough, a supplier will generally agree to smear the fixed cost across their per-call charge; but you will then face a minimum number of calls you will have to pay for each month (even if no one calls). To be fair, you will have a fixed cost internally too; and that cost needs to be factored into your business decision.
There is one midpoint solution you might consider: using your in-country distributors to supply non-English support. This alternative sits somewhere between internal and external service delivery. I have seen small software companies who provide support resources and extra product price margins to their in-country distributors, in exchange for the suppliers taking native language calls from customers, and then passing difficult problems back to the English-speaking support team in your home office. Again, all the background work still has to be done; it's just the solution implementation that changes. For a small software company, this is often the most cost effective solution.
You're right on the money. The validation of the point you make is NeXT's multiplatform strategy:
The bottom line on this is that to break Microsoft's dominance you have to break their revenue stream. Making applications run under MS Windows doesn't break that revenue stream. Making OSX run on x86 PC hardware doesn't break MS's revenue stream (as evidenced by Linux).
Apple's best strategy is to stay their course and continue to only sell OSX for Apple's own hardware; where they do this in the context of highly innovative, seamless, user-enabling solutions.
Also worth remembering---in the context of your point---is Apple's own Macintosh Execution Environment (MAE) which ran on HP-UX and other UNIXes: a complete Mac emulation which ran very, very well. Apple's cancellation of that product was a little short-sighted; in my opinion.
Fat binaries, anyone? This already didn't work for NeXT.
If you're referring to the technical strategy (i.e., did fat binaries offer multiplatform portability), you are incorrect. Fat binaries worked very well: compile once on my 68K machine and produce an application that ran on 4 different hardware platforms (5 if you count the unreleased PPC product).
If you're referring to the business strategy, then you are right. The ability to run NeXTSTEP on 4 different hardware platforms didn't save the company the way they had hoped it would.
In 1999--2000, we tried doing what you describe (at the company I work for). We have a large WAN with a couple of hundred sites scattered around the world. We used a commercial product called Asset Insight to do the scanning on UNIX, and we used MS SMS on the PCs. Note, we have a very small number of Macs and it wasn't cost effective to address them in the project scope.
Asset Insight and SMS allowed us to tier the data collectors: large sites consolidated their scans and then forwarded the consolidated data on to the global data collector. This was very necessary to keep network utilisation in a predictive state.
The project's ultimate stumbling block became focused within the PCs and workstations themselves:
We still have the system deployed, but it turned out to be much less useful than we had hoped---plus, it is very labour intensive:
Our approach with the data today is to focus on the major applications and OSes in use, and not worry too much about the little things. Our security team watches CERT et al and this provides the software management team with some direction w.r.t. the applications to stay on top of.
Sorry I don't have any software recommendations, but I hope our experience will assist you in your planning.
What you suggest should be trivial but isn't: no one has written any tools to import all Outlook's contact fields into an LDAP database. There are several projects that do a partial job of it, but they all require that the user be very conversant with LDAP. In other words, there do not appear to be any "out of the box" solutions to the problem the poster has posed.