Windows 7 Deployment: Part I

There is an old adage that claims “knowledge is power”, and if you believe that then, well, I’m going share a little bit of know-how in the realm of Windows migrations to those in the frantic rush to migrate off Windows XP before the April 14^th, 2014 deadline to do so.  This isn’t a comprehensive guide, but more “talking points” of things you need to consider. While I won’t claim a knowledge monopoly on the subject, having recently completed a 2-year, 150,000 client migration Windows 7 (with over 6,000 applications, 200+ countries, and nearly 10,000 physical locations), I think I know a little on the subject, and now happily share it with those on or about to go through the same trails and tribulations as I had the joy of enduring.

Assuming all of the pre-migration work of business case approvals, steering board committee commitments, approved budgets for resources, and even preliminary timelines/milestones have been set, let us get right into the migration fun.

Step 1. Discovery

Before one can begin migrating, one needs to know what they are migrating, how many they will migrate, and whether or not they can actually be migrated.  If you are a small, 1 location shop, more likely you can spend a few days physically counting the PCs and looking at their specs and applications to see if they meet Microsoft’s or your business’ requirements.  After all, not all of your PCs are going to be reusable.  However, in big shops, spanning hundreds or thousands of locations, multiple-countries, etc … it is just not feasible to do a manual discovery.  You’re going to need tools.

You’re going to need to know the following:

How many PCs are in scope

Although somebody used a relative “good guess” for the business case to start the project, you are going to need to find out how many PCs you have in your estate as best you can (by location, country, business unit, etc … helps with planning).  There are a few ways to do this:

a. Active Directory Object Count:  Depending on your Active Directory architecture, you can quickly get a good guess of how many objects you will need to migrate.  However, I’ve never seen a clear and accurate AD count.  Many machines somehow make it off of the domain, have server names instead of desktop names (or vice-versa), named wrong (location codes or even country codes can be wrong due to people moving locations within the company), etc.  The information is useful, but you’ll need to “triangulate” this information with better methods.

b. Centralized Desktop Management Tools:  The last contract I was on ran primarily an Altiris environment (lots of different tools exist however), so we were able to do Altiris queries for machines and their specs.  This tended to wield a good result, but it was still not accurate enough for our taste. Too many people in the old environment had local admin rights, and they usually removed the Altiris client when they had they chance, so you miss a lot of machines.  Not only that, the data in Altiris is only as good as Altiris (or any other system) is managed.  While it wasn't god awful, there were a lot of inaccuracies  with collections which were not suitable for gathering accurate data.  Again, good “triangulation” type data, but doesn't stand on its own.

c.  Discovery scripts:  What I found to be the best was a good ol’fashioned script that could be run locally (as an .exe) or as a login script via AD (or deployed as a task via Altiris or other tools if available).  In these cases, a nice PowerShell script can be your best friend.  Able to do a powerful WMI query, you’re able to pull all the information you need for a very robust discovery: host-name, physical specifications, applications, instances of those applications, user profiles … the whole lot!  What you will need is a good few weeks of running this script to get accurate data.  But after a few days, you can already get a good idea of what’s coming and start preparing for the next ugly steps.

The technical specs of those PCs

In some shops, you will go “greenfield” style which means that you will order (or already have ordered) new PCs for everybody.  This simplifies a lot of things, but it’s not the cheapest solution for most companies.  When “new PCs for everybody” isn’t feasible, the discovery information will tell you which PCs need to be replaced, which PCs can be upgraded to meet spec (ie...memory or HD upgrades), or which are already go to go for the OS swap. 

All these factors make a difference in re-deployment times and hence planning.  Moving data from one PC to another simply takes longer than keeping data on a machine and just upgrading the OS.  Therefore, make sure your company specs meet or exceed what will be needed for the new environment and get right to it.  New hardware orders take time.  When dealing with literally tens of thousands of new PCs, you can look at a 4-6 week delay easily.  Longer in most cases (see Global Images, Specs, Drivers below for additional duty to start in parallel)

The applications running on PCs

The real “meat & potato” of migration time deals with applications and packaging.  Don’t let anybody tell you different.  Yes, moving data from one PC to another can be cumbersome but you can buy or make tools that automate the process.  You can even automate to a large degree the installation of applications (as we did) on new/refreshed machines.  However, finding source files and testing those applications beforehand aren't easily automated.  You’ll need a team of packaging gurus, lots of luck, and some good testing if you want migration day to go smoothly. 

Take any liberty with shortcuts during this phase (no testing, lazy testing, messy testing environment), and you’ll pay.  Ooh, you’ll pay.  Make sure as the discovery script starts to populate the list of applications in use, you get the responsible people “white listing” the applications business will need, have licenses for, or are willing to pay for (and if they’re open source or free, are willing to support and pay packaging costs for).  Also if you’re packaging for remote deployment (via Altiris, or another centralized DMT), make sure you have a corresponding package to install manually as well.  This will save a lot of time when you find out a user is missing a business critical application.  In fact, all needed applications should be installed during the migration process, and desktop management tools should be use only in cases where local engineers aren’t available and something needs to get delivered.

Global Image, Specs, Drivers

The above processes are the first things you need to do, but at the same time, you should have already worked out a base image for your entire organization (Windows 7, company screen saver, applications that EVERYBODY gets, drivers for specific hardware types).  The image is the base of your migration.  However, it’s really only the base.  You cannot do a large, mass migration with an image because not everybody has the same software needs – and it’s a licensing nightmare (or non-compliance) if you deploy a lot more software than you have licenses for.  That’s why a base image should only contain software that your entire organization uses globally, nothing else.  Any software that is country specific, location specific, business unit or division specific, belongs to another process and not the global core the image.  This should be “made” and tested on the hardware you’re going to support (and include drivers for supported hardware only) during/before the discovery process is completed, so the tools needed to migrate can be completed and ready for duty.

Oh, and don't forget ... 32-bit or 64-bit ... what's needed and what are you willing to support?  95% of your organization won't need more than what 32-bit can offer.  So choose wisely, as support both platforms, means packaging for both, costs for both, etc ...

To be continued ... UATs and Pilots

What is Vendor Managed Inventory (VMI)?

I've seen the term Vendor Managed Inventory (VMI) used in about a million different manners now, and I just realized that the term is so liberally used, it can be cut up into various pieces that might make more sense for those uninitiated with or considering a VMI move in the supply-chain management world.  I don't want to argue the merits or demerits of VMI, I could probably write a book about it (whew! Looks like I don't have to?), but my take is that it's broken down into a few categories (I'm making it really simple for quick guide like sake):

Vendor Managed Inventory – Supply Side

Vendor Managed Inventory (VMI) in its purest form is when a vendor (supplier of goods) manages the inventory level AND stock level of its goods on a buyer’s (demand side) premise.  That is to say, they are responsible for scheduling / delivering a set amount of their inventory to a buyer’s stock room, and also re-stocking the buyer’s shelves with their goods.  Requisite levels of inventory are determined by sharing point of sales data (POS) and analyzing it in order to predict the best inventory level possible for the buyer based upon evaluated sale trends. 

Generally this system isn’t used as it requires the supplier of goods to be on site continually to make sure shelves are stocked.  This could mean a permanent resource on site or a daily visit to the buyer's location to ensure shelves are stocked and consumers have access to buy the goods.  With expensive, large, or slower moving goods, these human resource needs might not be as demanding, but the risk of losing a sale is very real if the good in question is not available to the customer seeking the product.

Vendor Managed Inventory – Supply/Demand collaboration

This is a growing, and usually more successful, form of Vendor Managed Inventory (VMI).  In a collaborative effort, both sides share sales data and analysis in order to fully optimize their inventories and sales opportunities.  In such cases, both sides divide up responsibilities (by agreement) and do their best to support each other as means allow (this can mean a lot of human communication, physical visits to buyer’s site by vendor, and  even sharing human resources at loading bays or even stocking store shelves, to get the job done).  Goods may be on consignment, delayed payment (90 day pay period on invoices), or purchased outright -- depending on agreement.

Vendor Managed Inventory – Buyer side

This is probably the most common form of Vendor Managed Inventory (VMI).  In Buyer side centric models, Vendors are usually leaving goods on consignment at the Buyer’s premise, and/or invoicing for a 90 day or more period before getting paid ... giving the demand side buyer time to make sales and earn cash before actually paying for the goods.  When this happens, usually the buyer is the sole entity responsible for keeping shelves stocked in order to make sales.  However, depending on the relationship and agreement, this type of relationship may demand that the supplier take back all goods not sold or alternatively that the buyer pay for the goods regardless if they’ve been sold or not.  Not the best system for creating trust and a positive business relationship among partners (hence why it’s in slow decline), but it’s still today the most dominate form of VMI.  Large players like Walmart almost use exclusivey this model, because they can.

Buyer Managed Inventory

This method is all but dead in the FMCGs business to all but the smallest players.  In this relationship, the buyer is wholly responsible for pre-purchasing goods to sell, incurring losses on items not sold, and responsible for all stocking/restocking of goods that are customer facing.  The vendor plays no role in the inventory process aside from dropping off goods at the bay doors of the buyer’s place of business.

Of course, there are hybrids in-between the above -- each one has a positive or negative element to them that might be better or worse for the supply or buyer involved.  Which one do you use?  Or which hybrid model do you use or do you think is best?  As stated above, these are mainly in the FMCG world, but they could apply to others as well.  Thoughts?

 

What makes a successful Project Manager?

I was recently asked by a recruiter (who “cold called” me for a job I didn't deem I was qualified to fulfill) to describe the attributes of a successful project manager.  I think my no holds barred replies shocked him a bit.  I said uncensored (make sure there are no children present):

•  To know what the fuck you’re talking about (I don’t know why I dropped the F-Bomb to a stranger, but I did …): Basically, don’t say “I know” if you don’t.  I have no problem saying I don’t know something and asking for help from someone with more wisdom in the matter than me.
  
•  To ignore process when it’s in the way*** : For example, if you have the bandwidth (time), and somebody needs your help – help them. Don’t make them raise tickets and bother 3 other people in the organization and waste their time to solve a problem.  Especially if it’s a customer.
  ***This can even work in more serious changes like production rollouts, but you really have to know what you’re doing.  You're either a hero or fired.  Not for the squeamish.
  
•  To garner social capital with your teammates and customers on a regular basis … ie, get shitted (drunk) with them once in a while and have some fun.  If you don’t drink, that’s fine, just don’t be a bore.  Nobody wants to help people who aren't fun, and they will do so only by “force” or necessity. 

That’s it.  All the certificates in the world mean nothing (Yes, I’m Prince2 certified, but I was forced to do it!).  I knew many PMs with certificates covering their walls, but they were notoriously unsuccessful because nobody wanted to help them (see point #3 above), they moved way too slow (see point #2 above), and they tended to escalate way too much (instead of trying to find the solution themselves in a diplomatic manner …. point #1 kinda applies).

There is nothing magical otherwise.

The importance of productivity ...

As I get into the final phases of development before the first release of my smart shelf solution, I am focusing a lot on usability and productivity features.  Outside of elite software development circles, these intangibles are still little understood and highly undervalued in the IT world.  Such features are always hard to elucidate to potential customers because they’re immaterial (not easily written into a feature list) and can usually only be perceived after the fact (ie… after using them).

When I say productivity what does that mean?  Well, there is the dictionary definition of it, but let me give you an example:

Many years ago I got the opportunity to work for a new start-up ran by some real math geniuses at JetBrains.  When I was asked to come on, it was a small team just releasing the 2^nd version of their now industry famous and unbelievably awesome Java IDE IntelliJIDEA.  These guys were the first to put refactoring features into a Java IDE and not only that, made it quick and easy to use.  Developers (their niche market) saw the value immediately and sales quickly took off.  A simple refactor like “rename” immediately saved 10s of minutes if not hours of manual (and error prone) work renaming items in your code.  You could now fire up the “rename” refactor with a push of a button, and all (for example, class names) within the entire project would be renamed to whatever you chose (error free).  Seems simple in retrospect, but it was a huge time saver at the time, and companies were willing to pay for such features.   Here’s why:

Let’s say you pay a developer 80,000 USD per year to program for you. He works 8 hours a day, 5 days a week, 4 weeks a month – an average of 20 days per month.  That yearly salary roughly translates into 6,666 USD per month, 333 USD per day, 42 USD per hour, .70 cents per minute.  This new feature saves 15 minutes per day.  Time = Money, so around 10 USD per day of developer time (ie… more work completed in the same amount of time).  Now, basic math: 10 USD per day = 50 USD per week = 208 USD per month = 2500 USD per year.  The software license cost was 500 USD.  That’s 2000 USD in increased productivity or programming value for that 1 developer.

And of course, that wasn’t the only feature (the tool had way more, with much larger productivity savings, but general time savings per day with the new tool was probably around 1 hour a day total).  Other elite programmers understood it immediately and had their bosses buy it; in companies where there was no budget, or worse, somebody who did not understand productivity was in charge of finances (which is usually the case), many programmers bought the software with their own money!

Then came the competition.  As our software added these productivity features, other vendors started to add them as well.  In this market, our competitors were open source software Eclipse (funded by IBM) and NetBeans (funded by Sun Microsystems).  Backed by billion dollar corporations, the foundations running these open source variants offered their software FREE, with features rivaling IntelliJ IDEA – maybe always 1 or 2 steps behind, but basically great value for the money (free!).  But you know what, although on a 2 dimensional feature list, they could compete with similar features, they still could not compete on the productivity side.  Their “rename” feature might work just as well, but to use it, you had to take your hand off of the keyboard, click around on the mouse, and basically go thru 4-5 steps to invoke this feature.  With IntelliJ IDEA, you needed just one press of a button (superior usability).  To this day, JetBrains is around, making a ton of software variants for different platforms and languages (all of them born out of IntelliJ IDEA) and always keeping 1-step ahead on productive features against their rivals.

That’s what tools you buy for your company should do.  If they complicate things, then they really do not have much productivity value.  Having played with many of the leading ERP system variants and their modules (SAP, Ariba, ex-People Soft now Oracle, Salesforce, and even smaller system), some of them are just horrible to use.  Slow, complex menus, nothing intuitive about them when using them … they’re not productivity inducing at all and even add some initial complexity to the organization (usually requiring expensive trainings, consulting for refinement, etc….).  Such systems shouldn’t be that way, but they are.  And they rule the logistics world.

However, knowing the above ... how can one sell “productivity” to a potential customer if the customer is unwilling to try something new, or due to the size of the company at hand, it’s simply impossible to rollout and demo a new product in their environment?  This is a problem I’m looking to answer.  And it’s a question supply-chain related companies need to figure out as well.  Being dominated by slow-moving, expensive 800-pound gorillas isn’t doing their organization (or the industry!) any justice, they need to internally think of ways they can “test” disruptor like chasm crossing solutions at the same time, to keep their current vendors honest and innovating.  Stay tuned! :-)

-

Inventory vs. Stock

In my entrepreneurial quest to redefine how shelf stock levels are managed, I'm coming into a rather interesting dilemma in choice of words to use in the English language.  Generally, I am using "stock" to define items on a shelf for sale and "inventory" for items that will be for sale, but are not yet customer facing (ie... in the stockroom!?!, on a truck being delivered to a store, etc.).


As an example, if something is "out-of'stock" what does that mean to you?  According to its general definition, it means the store no longer has that item available for sale.  However, what is it called when the customer facing shelf is empty with the item you want to buy but the stock room is full of that item?  In the this article about Walmart's inability to keep its shelves full with goods, they refer to it as "out-of-stocks".  You see the confusion?  They have goods in the back stockroom, but the goods are not on the shelves for sale.  Do those of you in retail have different words for these two issues, because I'm not able to find a clear separation between them.  I've seen somebody refer to missing items on shelves as "stock gaps" but I don't see it being used anywhere else.

For the solution I'm working on, I'm only concerned with fixing the gap that the customer sees.  "Stock gaps" or "out of stocks" or whatever you want to call them, is what I'm trying to fix.  I am not (yet) trying to make my own inventory management system, as there are a plethora already out there (albeit most of them are horrid and have poor usability and data analytics).  So, in the meantime, I'm focusing on stock levels, not inventory levels, if that makes any sense at all.

In the VMI world, the two words stock and inventory are almost used interchangeably, making it even more confusing and even more difficult for me to articulate the problem I'm trying to solve.  Maybe the specific words or meanings exist and I just don't know them, if so, I'd like to hear them so I can use the proper words in describing what I'm trying to solve. Anybody?

Rebooting the Blog - Hello Again! ;-)

Well hello again, it has been a while since my last post :-) I've been enjoying life so much that I've not thought much about posting. However, summer is ending and I'm self-inflicting some new misery on myself by developing some new software to deal with a little problem that always bugs me: empty shelves.  Not just any old shelves, but I mean shelves that should have things on them, usually things that I want, and they don't. Being empty in the age of Big Data (current leading trend word in the logistics world, slightly ahead "in the Cloud") is simply unacceptable although understandable: Big Data is basically dependent on a slow, analytic process of trending future market events.

Data collection this way almost never happens in real time (usually in scripted collections during off-peak hours), and this is why it may take a day, 2 days, or even more for your favorite goodies to reappear back on the shelves.  Even systems that work in "real-time" don't work in real-time.  Some more agile systems (usually in smaller stores with more agile POS systems) don't collect the data until an item is sold.  What if you remove the last item off of a shelf and then keep shopping for another hour?  A few more people will miss getting what they want and the store will lose another sale.


How can this be solved then?  Simple: By tracking product movements at the shelf-level.  This type of tech has been on the radar of big players like Walmart for years, betting on RFID to help do it, but because of continued RFID tag costs and the extensive labor needed to implement and maintain, it hasn't come to fruition. Thus, stores like Walmart openly say that they have a 90-95% in-stock level.  More so, it seems the items aren't out-of-stock, they're just sitting in the stock room.  In Walmart's case, that 5-10% "out of stock gap" is worth billions alone.  Hmm.

Anyway, back to me. :P  I'm making some simple, agile software that will send alerts when stock is getting low and/or empty, so stock people know exactly where and what to re-stock.  I'm currently targeting VMI vendors, so they get an alert when to re-stock the shelves in the buyer's location (or can keep pressure on the buyer to keep their goodies stocked).  It'll be a good performance management tool to measure a product's popularity (time/dates they move off shelf, location, etc..), how fast the buyer re-stocks (if they're responsible) or if the vendor is responsible it will help them organize their supply-chain/human resources, on a real-time basis, in order to keep their goods on shelves for sale.

So the next time you go shopping at any FMCG store, see how many stock gaps you can find and then see how long it takes for them to be filled. You'll be amazed.

Goodbye Gowalla, for now ...

Well, I have officially stopped using Gowalla. I just didn't like its privacy settings. Even though I set my Privacy settings to "Private" -- which means via the web, users could not see where I was checking in ... they could still see the photos I was posting at check-ins. I didn't like that. Not at all. The Czechs have a word for that called "drzý" (something like "insolent" or "brash", but not really). Over the years, I've helped them grow by checking in everywehre and creating new locations, and now they've been purchased by Facebook. Congrats guys! Now Facebook own the top two worse sites for privacy settings on the internet.

Once you guys can fix that, I'll be back ...