My big project this year was to move our corporate email to Exchange Online, part of the Office 365 suite of services. That was last summer. Overall the project went well and supported the divestiture of our company from our previous owner. There have been some other challenges along the way, but it's been tremendous in making email more easily available to our employees worldwide while simultaneously lowering the costs to provide and manage email.
Moving email to the Exchange Online was just part of our move to the cloud. Certain of our products were moved as well, presenting their own challenges, but overall removing a great load off our network and server infrastructure.
The key challenges in moving to the cloud are process, not technology. Cloud services always involve another party - the cloud providers. Any service built in the cloud requires solid communication between the provider and your IT staff. However, even with good communication, having processes updated to account for that information is equally important. When customers report issues or outright outages, being able to trace the cause means your people and the cloud provider need to be tightly coordinated.
If you have another party involved, such as an outsourced service provider, this becomes even more complicated. Customer calls with Problem X. The service desk diagnoses the issue as being with your service. They escalate to the service operator - who then checks logs and sees performance volatility. Is it traffic volume? A bug in the application? A security breach? Or, is your cloud services provider experiencing issues?
Engineers tend to either run down a path of building new services without a support model, or working in deep silos where cross-functional visibility is extremely limited. In Information Technology, there's a tendency to patch processes to connect dots but not four.
Overcoming procedural and communication barriers is a challenge for any organization, but is critical in moving to the cloud.
Wednesday, December 24, 2014
Sunday, December 7, 2014
Name-Dropping
Pretty succinctly describes why dropping a superior's name isn't a great way to get things done.
https://www.linkedin.com/pulse/article/20141206170559-1510816--john-said-why-name-dropping-is-cheating?trk=tod-home-art-list-small_1
https://www.linkedin.com/pulse/article/20141206170559-1510816--john-said-why-name-dropping-is-cheating?trk=tod-home-art-list-small_1
Thursday, March 13, 2014
X vs. Y
I came across the following link, and while it's on a pro-Apple site it makes a pretty good point about IT debates in general.
http://www.tuaw.com/2014/03/12/why-the-mac-vs-pc-marketshare-debate-is-outdated/
Most of my IT career has been spent supporting Apple products - let's say 18 or the past 20 years. I got tired of the Mac v. PC debate after, oh, year 2. After that it was more of a parlour game, till, say, year 6. After that - really, I have better things to do with my time that argue que es mas macho, Apple or Microsoft, Macintosh or Windows.
Most products have certain strengths and weaknesses; that's how they compete. There are certain things they have to be able to do - but how well, how interoperable they are, what sort of network effects they burnish - all competition. In my current role, I see this playing out against numerous requirements:
Lync v. Jabber
Jive v. Sharepoint
iOS v. Android
Mozy v. CrahsPlan
Cloud v. On-premise
http://www.tuaw.com/2014/03/12/why-the-mac-vs-pc-marketshare-debate-is-outdated/
Most of my IT career has been spent supporting Apple products - let's say 18 or the past 20 years. I got tired of the Mac v. PC debate after, oh, year 2. After that it was more of a parlour game, till, say, year 6. After that - really, I have better things to do with my time that argue que es mas macho, Apple or Microsoft, Macintosh or Windows.
Most products have certain strengths and weaknesses; that's how they compete. There are certain things they have to be able to do - but how well, how interoperable they are, what sort of network effects they burnish - all competition. In my current role, I see this playing out against numerous requirements:
Lync v. Jabber
Jive v. Sharepoint
iOS v. Android
Mozy v. CrahsPlan
Cloud v. On-premise
Even outside IT, you'll find people arguing Ford v. Chevy, stick v. automatic, hybrids v. SUV maybe. Do we still even have SUVs?
Putting on my MBA hat, all we should care about is how much does it cost and what service am getting out of it. Most large organizations have multiple platforms, and supporting them all raises costs. Yet, to drop a platform may mean shuttering a process or service that someone, somewhere, considers to be vital.
Saturday, February 15, 2014
Information Technology: Who is the Customer?
If you have ever worked for a large company, you probably fall into one of two sides to the following scenario: you are either a user of Information Technology (IT) services, or an administrator. You're either powerless, or all-powerful.
With the consumerization of IT, that model has begun to change. The "users" consume IT services in their personal lives, and have questioned why IT can't provide better service. Furthermore they react to IT the way they might against a service monopoly or duopoly, and jump at any chance to subvert or work around the system.
Meanwhile, IT professionals have been faced with fewer resources, with various functions outsourced, offshore, and with few dollars all around, all while being told to treat "users" as "customers", to hear the "voice of the customer", and be more "responsive" to "customer needs".
This begets the question: who is the customer?
Typically, in any business, the customer is the one who pays the bills. You order a sandwich, you're the customer. You buy a car, you're the customer. Being a customer is great in service economies, where firms compete on who can provide the best service. The customer is King (or Queen).
However, in a large company, the consumer of these services is not necessarily the customer. Services are provided to these consumers in order for them to perform their jobs. Services such as email, network access, and software distribution are consumed by employees but ultimately paid for by the company - which in turn ultimately means the shareholders.
Whether publicly or privately held, a company exists to increase shareholder value (more broadly stakeholders, if you lean European).
Why is this an important distinction? The consumers of IT and the customers of IT amy conflict, or have different priorities. Often this results in IT getting caught in the middle, enforcing the requirements of one at the expense of the other. I'll give two examples.
One example would be a group of product developers who need to collaborate with external teams, ether as part of a joint venture or a contractual relationship. The technology consumers want to share files easily, perhaps through a third party cloud solution such as DropBox. However, the customers - the owners - have very clear concerns about intellectual property and other sensitive data being stored, and have explicit policies against storing data on external solutions. The result is additional administrivia for the consumers to work through in order to get their external teams access to commonly shared data. Curse you IT for making life so hard!
Another example would be cost modeling for a product platform - let's say some sort of database the company will sell access to. This will be a revenue-generating product. A hosting center offers a solution for $3,000 a year. The internal IT group, after months of review, says they can do it for $24,000 a year. On that basis clearly the first option is the better one, but are these apples-to-apples comparisons? The consumers are the only ones who see both offerings, and the first excludes things they can do without - backups, monitoring solutions, and so on. The customer - the owners - do not want any service outages for this product. Without these additional services, any outage could go on for hours, even days.
The customer model in IT is similar to the insurance industry: the consumer of services does not pay for them, or pays for them indirectly. I is easy to ask for better service when it isn't coming out of your pocket. It's also easy to be led astray by lower prices that do not offer the same level of service. Technology aside, I expect this will be the next transformation of IT: how to clarify costs and facilitate communication between the consumers and the customers of services.
With the consumerization of IT, that model has begun to change. The "users" consume IT services in their personal lives, and have questioned why IT can't provide better service. Furthermore they react to IT the way they might against a service monopoly or duopoly, and jump at any chance to subvert or work around the system.
Meanwhile, IT professionals have been faced with fewer resources, with various functions outsourced, offshore, and with few dollars all around, all while being told to treat "users" as "customers", to hear the "voice of the customer", and be more "responsive" to "customer needs".
This begets the question: who is the customer?
Typically, in any business, the customer is the one who pays the bills. You order a sandwich, you're the customer. You buy a car, you're the customer. Being a customer is great in service economies, where firms compete on who can provide the best service. The customer is King (or Queen).
However, in a large company, the consumer of these services is not necessarily the customer. Services are provided to these consumers in order for them to perform their jobs. Services such as email, network access, and software distribution are consumed by employees but ultimately paid for by the company - which in turn ultimately means the shareholders.
Whether publicly or privately held, a company exists to increase shareholder value (more broadly stakeholders, if you lean European).
Why is this an important distinction? The consumers of IT and the customers of IT amy conflict, or have different priorities. Often this results in IT getting caught in the middle, enforcing the requirements of one at the expense of the other. I'll give two examples.
One example would be a group of product developers who need to collaborate with external teams, ether as part of a joint venture or a contractual relationship. The technology consumers want to share files easily, perhaps through a third party cloud solution such as DropBox. However, the customers - the owners - have very clear concerns about intellectual property and other sensitive data being stored, and have explicit policies against storing data on external solutions. The result is additional administrivia for the consumers to work through in order to get their external teams access to commonly shared data. Curse you IT for making life so hard!
Another example would be cost modeling for a product platform - let's say some sort of database the company will sell access to. This will be a revenue-generating product. A hosting center offers a solution for $3,000 a year. The internal IT group, after months of review, says they can do it for $24,000 a year. On that basis clearly the first option is the better one, but are these apples-to-apples comparisons? The consumers are the only ones who see both offerings, and the first excludes things they can do without - backups, monitoring solutions, and so on. The customer - the owners - do not want any service outages for this product. Without these additional services, any outage could go on for hours, even days.
The customer model in IT is similar to the insurance industry: the consumer of services does not pay for them, or pays for them indirectly. I is easy to ask for better service when it isn't coming out of your pocket. It's also easy to be led astray by lower prices that do not offer the same level of service. Technology aside, I expect this will be the next transformation of IT: how to clarify costs and facilitate communication between the consumers and the customers of services.
Wednesday, January 1, 2014
Months Later
How did a year and a half go by since my last post? I chalk it up to a slew of developments at work, and to being pretty well out of business school. However, after months of tumult (I would say, tumultuous doldrums, ie hurry up and wait), I figure it's time to re-start this blog to talk about some of he business problems I'm confronted with these days.
First, to set the scene: In 2012, my employer opted to outsource nearly all of its IT engineering and operations. About 90% of my colleagues were given (and took) the option to continue in their roles under the outsource provider; a smaller number of us were retained within the new IT organizations within the companies.
Second, the Education division was going to be divested from the larger company, either on its own or sold to another party. Ultimately, McGraw Hill Education (MHE) was sold to a private equity firm in 2013, and it is with MHE that I now ply my trade.
Most of 2013 and 2014 have been and continue to be filled with divestiture and re-organization: spinning work off to the new provider, and separating our infrastructure from the former parent company. I've led efforts in both tracks for endpoint computing, which is essentially all workstations, mobile devices, and the services to support them. It's plumbing, but vital plumbing.
So what are this year's challenges:
Create an an IT support organization that provides forward guidance on emerging technologies as well as support for existing technologies.
Finish the creation and migration of endpoint services for a global enterprise of 6000+ employees and contractors, without disrupting existing services.
That's it. these are broad buckets, and the details will follow - to list them all now would beggar anyone's attention span. Some details I'll have to be coy about, but the larger processes I expect will be lessons applicable anywhere.
First, to set the scene: In 2012, my employer opted to outsource nearly all of its IT engineering and operations. About 90% of my colleagues were given (and took) the option to continue in their roles under the outsource provider; a smaller number of us were retained within the new IT organizations within the companies.
Second, the Education division was going to be divested from the larger company, either on its own or sold to another party. Ultimately, McGraw Hill Education (MHE) was sold to a private equity firm in 2013, and it is with MHE that I now ply my trade.
Most of 2013 and 2014 have been and continue to be filled with divestiture and re-organization: spinning work off to the new provider, and separating our infrastructure from the former parent company. I've led efforts in both tracks for endpoint computing, which is essentially all workstations, mobile devices, and the services to support them. It's plumbing, but vital plumbing.
So what are this year's challenges:
Create an an IT support organization that provides forward guidance on emerging technologies as well as support for existing technologies.
Finish the creation and migration of endpoint services for a global enterprise of 6000+ employees and contractors, without disrupting existing services.
That's it. these are broad buckets, and the details will follow - to list them all now would beggar anyone's attention span. Some details I'll have to be coy about, but the larger processes I expect will be lessons applicable anywhere.
Subscribe to:
Comments (Atom)