1) Software as a Service (Saas): You pay to use software that is owned, maintained, backed-up (hopefully!), and hosted by someone else. Salesforce.com is an example of this. So is Google Apps. In both cases, your organization is paying a monthly or yearly fee for your employees to use their software.

Usually, all that is needed to use the software is an internet connection. This model places the lowest demand on your internal I.T. resources. It also makes you the most dependent on the
vendor.

SaaS is a mixed blessing when it comes to disaster recovery planning. If your building burns down, all you need is a computer with an internet connection to access your SaaS applications. So, from a DRP standpoint, it couldn’t be easier, right? But, what if the SaaS vendor suffers a disaster? What if they lose your data? Now things get complicated.

2) Managed Services: The managed services model of cloud computing is leasing a combination of hardware, operating systems, and software from a provider, usually a data center. For example, instead of owning your own servers, you could lease a server and operating system from a data center. They would provide to you a physical or virtual server with a server OS of your choice. The provider is responsible for the hardware and operating system, you are responsible for applications.

This model will eliminate some work for your IT staff, but not much. But, it is the model that is most disaster-proof, provided you choose a rock-solid vendor.

3) Private Cloud: In this cloud model, part or all of your server infrastructure has been moved to a data center. You still own your hardware and software, but you are leasing power, bandwidth, and space for your equipment to live. This moves you away from location-dependent computing: you should be able to access your applications from your home or hotel room almost as seamlessly as from your office.

The demands on your I.T. staff won’t decrease under this model, and your disaster recovery planning still needs to take into account server failures and similar localized problems. But, being in a data center, with off-site backup, is one of the few credible disaster recovery plans I know of.

Which one of these are right for my organization? The answer is most likely a combination of all three. Companies under a certain size should consider using SaaS exclusively. It keeps costs down and eliminates the need for an internal I.T. resource. But, as companies move to an enterprise mindset, it makes sense to begin to own your own applications and perhaps eventually, to own your own hardware and software. At least, that is what makes sense as of this writing. In a future blog post, I’ll discuss where I see enterprise IT computing in the next few years.

But, often, it isn’t a case of being motivated to hide information, it is a case of being unmotivated to document something that is boring. Many people end up in the technical field because they enjoy trouble-shooting and solving problems. But, once a problem is solved, they are bored with it.

Regardless of what the motivation may be, it is unacceptable for a technology professional to hoard information. Not only should your systems and processes be documented, but most everything that most I.T. staffers do should be recorded in an organized and searchable manner. This will greatly decrease the amount of time reinventing the wheel.

No organization should ever feel held hostage by their I.T. Department, any particular staffer, or by any vendor or group of vendors. A senior executive should have complete access to all documentation and should audit it on occasion to make sure it is current.

If you’d like a checklist of documentation you should have, and some suggestions for simple and quick audits, please contact me.

Look very carefully at all of your maintenance agreements. Many companies accept that fact that they need to pay tens of thousands and hundreds of thousands of dollars in maintenance and support. You probably don’t.

If you have a support agreement for your ERP system, call the organization providing support and ask what the alternatives are. Wouldn’t it be better to not renew that $30,000/yr agreement if you knew you can buy support as needed in $5000 blocks?

Look at every monthly recurring cost. How many of these do you really need? How many can you cancel?

The ideal I.T. department will be able to move quickly to lower costs dramatically. If your I.T. department has been doing its job the last several years – staying up with updates, refreshing machines on a regular schedule, mitigating the risks of depending on vendors and staffers – then your company should be able to easily postpone all I.T. initiatives in a financial emergency. You should be able to cut staff, defer purchases, and cancel support agreements.
These steps are not ideal. Eventually you’ll have to restart spending on I.T. But in a financial crisis, your I.T. department should be able to save a significant amount of money.

In the case of corporate email, instead of having an email server or servers on site and paying someone to manage those servers, you would instead connect to an email server managed by third party, paying a monthly fee per user. There are some very compelling reasons to move some application to Saas, but the hype doesn’t always withstand sober scrutiny.

I strongly considered moving a client from their on-site Exchange server to Google Apps Premier Edition for their email. The end users would not notice much of a change – they would still use Outlook for email. I’m still figuring out how collaborative calendaring would work and how we would replace the public folders being used in Exchange, but I’m sure Google’s solution would be sufficient, if not superior.
The three issues that made me decide against moving the client to Google Apps are:

1. Control : Is the client ready to surrender control of a mission critical service to an organization that is largely unaccountable? Google App’s Premier Edition claims to have a 99.9% uptime guarantee, but the Service Level Agreement isn’t satisfactory – if they fall below 99%, then the client must request a service credit for 3 to 15 free days of service. Fifteen free days of service won’t make up for a day of email being down. Right now, if the client’s email goes down, they call us. We are 100% responsible for making sure it works. No excuses, no other vendors to blame. And if we don’t perform, the client is free to find a service provider who will.
2. Cost: Currently, Exchange 2003 is running on a Windows Server 2003 box. Besides patching it, there is no maintenance required outside of an unscheduled reboot every other month or so. So the cost of sticking with what they have is essentially zero. The cost of moving to Google Apps Premier is $50/user/year. For a 50 person company, this would mean writing a check for $2500 just to interrupt the status quo.
3. ITMG’s Business Model: This last concern is weak, and is similar to #1 above, but I can’t simply dismiss it. Is it a good idea for me to steer my clients toward using a service I have no control over? The worst case is this: I make the argument for moving to Google Apps, the client agrees, I move them over, and then there is a two day Google Apps outage. I can’t do anything at all to help the client in the immediate term. I’m uncomfortable with this…it positions ITMG as a sales organization (Buy some Google Apps!!) and not a service organization. As my clients know, I have no problem working ourselves out of a job – but we do this by making client systems more reliable and predictable, not by asking them to trade a reliable system for one that we can’t control.

All that said, I think Google Apps is an excellent choice for many organizations. C! Tech Solutions. just moved the Ferndale Chamber of Commerce over to Google Apps, and they have been thrilled with it. For small organizations, for less corporate organizations, or for organizations that can stomach the idea of not being able to control their own destiny, Google Apps seems like a no-brainer. And, Google is an excellent company with a delivery-of-service record far exceeding the picture I paint when discussing concerns.

A big part of I.T. Management is risk management. In this case, at this point in time, the status quo is more than adequate, and the costs and risks associated with moving to Google Apps don’t justify the benefits.

Plant A was much easier to work with throughout the implementation. The supervisors were not pushy and they did not blow up when they system had problems that might have slowed production. Instead, they looked for ways to keep production flowing, letting us sort out the problems with the implementation at our leisure.

Plant B was not easy to work with at all. They demanded many changes. They required inordinate amounts of documentation and training. And when there were problems that affected production, they refused to find ways to work around the problems. They waited on us to fix whatever the problem was, even if it meant a loss of production. You can imagine that every time the new system caused a drop in production, the executive team heard about it.
Fast forward a year….Plant A was still easy to work with. The supervisors still kept production flowing. But the ERP implementation was a mess. The support burden was higher than it had ever been. The many work-arounds created during the implementation had become cemented processes. As a result, the new system was just as inefficient and fragmented as the one it replaced.

But Plant B, with the unreasonable management, was a resounding success. They rarely needed technical support. All of their employees were well trained. There were no work-arounds to impede the flow of information. The new system was performing exactly as hoped, with some departments seeing a significant decrease in busy-work.

Plant B took the time up front to get it right. At a significant short-term cost, they made sure that the processes and technology introduced by the new system worked, and that all employees knew how to use the system. They refused to accept work-arounds, because they knew how quickly a temporary work around becomes standard operating procedure.

Due to a variety of factors (none having to do with the ERP system) one of the plants as eventually shut down. Can you guess which one?

There are some legitimate reasons to do so. Among them are to make sure scarce bandwidth is not being used for frivolous tasks and to ensure employees are not engaging in illegal, unethical, or harassing behaviors. But when I’m told that “I want to make sure our employees aren’t wasting their time on the internet,” my response is “How would you like them to waste their time?”.

To be sure, the internet can be a time-sink. But so can the water cooler, the cafeteria, navel gazing, and phone calls. Producing reports for an executive that details how employees spend their time on the internet is not going to keep people from wasting time. It may well discourage people from wasting time on the internet, but I’m confident that they will find another way to waste time.

Another strategy is to deploy a firewall that prohibits certain sites and services. For instance, at one client, we block access to streaming media, instant messaging, social networking, gambling, porn, and hate groups. In my opinion, we should be blocking access only to porn, gambling, hate groups, and the like. This would allow employees to waste time updating their Facebook status, but is that such a bad thing?

The ubiquitousness of the internet and modern communications has caused many people to blur the lines between work and home/play/non-work. The younger the worker, the more likely she is to not feel that her job responsibilities are something she takes care of only M-F, 8-5. She may work remotely from home every night from 10 PM until midnight, because she feels she does her best work then and she doesn’t have to deal with interruptions. So, if she still comes into the office for a typical 8-5 shift, is it a problem that she spends an hour during the middle of the day updating her mountain-climbing blog?

Technology provides different tools for supervisors to use to manage their people. But, it doesn’t replace managing people. The best managers will see technological tools not as tools of enforcement, but rather as tools of engagement.

The truth is, there are a lot of terrible I.T. people out there. And, you don’t have to be a techie to find them. Here are a few ways to tell if your I.T. Dept needs an upgrade. If you’d like a more exhaustive guide, please request our white paper.

Your systems and infrastructure aren’t documented. You should be able to receive an immediate response to a request for current systems documentation. You don’t need to understand it, just know it is there.

Your I.T. staff can’t take a week off. Even if you have a one-person I.T. Dept, if someone in I.T. can’t take a week off – with no phone calls or emails – you have a problem.

You have firefighters and heroes in your I.T. Dept. Excellent I.T. Management isn’t glamorous. In fact, it is relatively anonymous. If your I.T. staff is constantly putting out fires or saving the day, they suck.

You’re told something can’t be done. Given enough resources, anything can be done. If you have a request that is difficult or costly to implement, you should be told why in business terms and presented with alternatives. You may decide that, given the cost, it shouldn’t be done, but don’t let your I.T. people you tell it can’t be done.

Your employees look for ways to bypass the I.T. Department. If your I.T. staff is unresponsive or unhelpful, your staff will figure out how to get things done without them. Proper I.T. Management requires some measures that end-users may not be fond of, such as restricting access to certain web sites or personal email, but your I.T. staff should be in constant communication with their clients – your employees – so that they are viewed as helpful partners, not enforcers of rules or the place where support requests go to die.

You could argue that the new ERP system is what made it possible to reduce head count. But, this isn’t true. Another plant in the same company had been operating with fewer people and more volume for years, under the old legacy system and under the new ERP system. What the new system did was to push people out of their comfort zones and shake up tired old excuses for keeping the status quo. What actually reduced head count – and costs – was the insistence and direction of executive management.

When I read “Investment Proposals” from software companies that include a ROI, I laugh to myself. There are very few applications that will have an actual ROI without a great deal of work from management to force the issue.

Many of the ROI calculations I see from software publishers make some astounding assumptions. For instance, if you are looking at software to allow end users to diagnose and fix their own technical support issues, the publisher may claim that you’ll save 40 hours per week of customer service labor, saving you the salary of one person. But, will you really lay off that person? Will you really save 40 hours, or will you just re-allocate labor by finding you need an additional 20 hours a week in your I.T. department, and 20 hours a week for a new position that ensures the quality of solutions posted to your self-help web site?

What is true, though – and this is important – is that the best applications will allow you to more easily achieve a positive ROI based on actual numbers and hard costs.

Reducing costs significantly is hard work. It requires painful decisions and taking risks. No software program will do this for you. Next time you look at an “investment proposal” from a software company, ask yourself: “What will this application allow me to do that I can’t do with our current systems?” and “Am I willing to do the hard work necessary?”

Managing the I.T. for enterprises like these means that we use a lot of tools to help us: enterprise grade anti-virus software, asset management systems, network monitoring tools, patch management systems, and issue tracking systems. We spend a lot of time monitoring servers and critical applications to make sure they continue to work and to avoid unplanned downtime. We have backups of data, backup workstations, contingency plans for when a server goes down, and disaster recovery/business continuity plans.

But all this is meaningless if an individual at a client can’t use his PC or laptop. At the end of the day, everything we do should support actual, individual human beings getting work done.

I had an end-user at a client call me the other day because he had some malware on his laptop that the anti-virus software does not catch. As I.T. Managers, we have to work to resist the urge to dive into the issue from an enterprise technology standpoint: why doesn’t this anti-virus program catch this piece of malware? When was the last time his laptop was on the LAN/VPN to receive updates and patches? Is he taking advantage of the fact that he is a mobile user to visit web sites that are prohibited when on the LAN?

All of these are important questions. But, most importantly, the individual needed the ability to get work done using his laptop. So we ended up doing remedial PC support – the kind of support that we politely refer to someone else when it comes from a micro-business or residential customer. Even with all of our enterprise grade tools and “we’re business people who understand technology, not techies who work in a business” attitude, what is most important is that the end users have the tools they need to be productive.

Let us know if you have any questions by commenting on an individual blog or by contacting us.