Acquisition and Procurement

Acquisition and procurement

A common problem that I see amongst companies is that individuals or departments within the company just go and purchase any products or software that they want to without IT's knowledge, and this causes some big problems. So you're going to want to make sure that part of the procurement process is to make sure that individuals are including IT for certain purchases.

You might hear these terms acquisition and procurement. They really are very similar in their meaning, and different people will have a different line of how they draw these two, so there's different definitions. Pretty much both of them just mean that you're getting a hold of ownership over something. This process is just getting a hold of ownership over something.

A lot of times you hear the term acquisition used in the idea of acquiring a company, or acquiring a product that you're taking on, a product maybe that you're going to sell, versus the procurement process is more of just goods and services that you're buying, products and services that you're buying for delivery of your product. So they might have a different nuance in meaning depending on who you talk to, but for this purpose we're just saying we're getting a hold of ownership over something.

Shadow IT

Every single company or organization that I've worked for has struggled with something called shadow IT. Shadow IT is when users or departments don't go through the IT department for some sort of process that they should be going through the IT department for, but instead they go around the IT department to purchase something or to do something. A good example of this is maybe they're purchasing a printer, maybe it's a headset, maybe it's some sort of product that they are purchasing for themselves.

Now, why this is bad is because, number one, IT could already have a surplus of this. They could have extra printers or extra headsets that they could just ship to the end user for the end user to use, and so now they're wasting money because they have not gone through the IT department that already has these products on hand.

Number two is they could be buying the wrong products, products that are against the company policy or against what the company is trying to do. For instance, somebody who buys the printer: maybe the company is trying to go printer and paperless and trying to just use everything electronic. Or perhaps they're trying to go all laser printers because they can be a lot cheaper than color inkjet printers, and so maybe they have certain policies like that, that you're going to spend a ton on ink if you go with the inkjet. So that could be an example.

Number three, it could be that whatever services or products that they're buying is just really difficult to support. For instance, they could be buying some sort of product that has all sorts of problems, and IT knows what products they're willing to support. A lot of times users will buy a product expecting IT to support it when they can't really support it.

Here's another completely different example. This has to deal with software as a service, some sort of service that was in the cloud. We had one department that was utilizing software as a service, these services that are in the cloud, and they uploaded some data into there and they had some services that they were utilizing. Well, what happened is the company went through a round of layoffs because they were downsizing, and some of the people that were in charge of this were laid off, and they were using their personal accounts to manage this. Well, now the company had data up in the cloud in a service that they couldn't access, and this is a big problem, a big security problem.

The process

So the company needs an acquisition and procurement process, a way that we can acquire different products and make sure we implement them correctly. It all starts out with a needs assessment, because users think they know what they need, but they might not know all the proper questions to ask. Or maybe we need to evaluate it from a company perspective: maybe it meets the needs of an individual department, but does it meet the needs of the company as a whole? So we need to go through a needs assessment to make sure that we're looking at this correctly.

Not only that, but then we do product research: what products are going to meet those needs? Because a lot of times users will choose a product based off of what they're sold on, not what's actually going to meet their needs, and they get sold on a lot of extra features that they aren't actually going to use.

Once we choose some products that are going to actually meet our needs, we need to go through a product and vendor evaluation and selection, where we're evaluating these products from a logical perspective and making sure that it's going to meet all of our needs and that we're choosing the best solution for us. Then we'll have to go through and probably get some sort of approval, depending on what the price is and what we're capable of doing depending on our position in the company. And then we of course go through purchasing it.

Don't skip the needs assessment

One thing that I feel like gets really overlooked in this process is the needs assessment. The needs assessment happens right at the beginning, or should happen right at the beginning. A lot of times people will go to a conference or go somewhere where they see a product that they absolutely love, that's going to change their life, that's going to be amazing, and then they get into rolling it out and it's caused all sorts of problems because they didn't do a proper needs assessment. So a needs assessment is a really important part of this whole process. From there you can make sure you have the right product and are rolling out the right product.

Too often people jump to this product research phase, or maybe even product and vendor evaluation, without looking at the big picture. They've been sold on something very specific when they need to take a couple steps back and look at what the actual needs are.

Let me give you one example. I contracted out for a company that had a lot of different daycare sites, and I was rolling out a database for them. It was a database that was going to track all of the kids that were logging in and out of this daycare site, so that way they could then roll us up into some billing and then charge the different customers. So it was going to track all of this, and it was a database to do that.

Well, they didn't go through it properly. They didn't go and make sure that we did a proper needs assessment up front to make sure it was going to meet their needs. So after a year of rolling this out, and it not going very well, they included IT at a proper level, and we determined that in fact it wasn't going to meet all of the needs that they had, that it was a software that just was engineered incorrectly for the needs that they had, and as a result of it, it was never going to do exactly what they wanted it to do. And so this is a great example where they should have included us much sooner in the process, to do that needs assessment before they ever started evaluating which products they were going to choose.

So the biggest thing with this is we need a solid process that makes sure it's a secure process, that includes checks and balances, and also includes IT so we can do the proper evaluation on: is this the right vendor, and is this the right product for that department, for that user?