Get in the Boat

Home > Other > Get in the Boat > Page 10
Get in the Boat Page 10

by Pat Bodin


  Lots of Red people in IT believe that efficiency is the main thing, so they work hard all year to save their organization money. The CFO sees those savings and is she impressed? Maybe not. She thinks, “I gave IT too much money! Next year, less.” Saving money in IT will not cause the functional leaders to think more of you. That said, if your savings allows your company to make their quarterly numbers, then that reduction in cost will be noticed because your savings has a direct impact on your company’s bottom line.

  Saving money is good. But simultaneously, if you want to speak Blue and be relevant, you have to get more bang for your buck; effectiveness. Here’s an idea for how to use that extra savings to be relevant. Instead of sending the money saved back into the financial coffers, place it into a special budget for you to invest in your functional leaders when they need it. Imagine this: You’re sitting in a meeting with a functional leader who says, “I need such-and-such amount of money on top of my own budget so I can purchase this tool and accomplish this goal.” You confidently commit: “I’m in. I think that is a great idea and I’m willing to support it from my own budget. I can’t float the entire purchase, but I’ll be the seed capital.”

  You’ve gone from being the person who saves money to the person who invests in the ventures of your functional leaders by supplying seed capital. Your perceived importance will skyrocket. The functional leaders will see you as a relevant Blue enabler. Money talks.

  Stop thinking about your budget as something you need to shave money off. Yes, you want to save money, but you want to save so that you can become the venture capitalist of your organization. When your functional leaders are short on funds, you want to be the first person they call. You become the angel investor.

  Sometimes, executives give poor incentives to IT, incentives that make saving money seem like the end goal. They say, “If you save money, we’ll give you a bonus.” That’s shortsighted and misguided. Incentives like “Reduce your headcount by 100 and get a 2-million-dollar bonus” are easy to achieve—fire 100 people, regardless of how that affects the organization!

  Thankfully, most technologists are not incentivized that way. But they still feel the urge to save money—an urge that must be harnessed. Saving money earns you no relevance per se. You can wield your savings as a weapon to win massive relevance by using them as seed capital for functional leaders’ projects.

  You will never have enough money to provide the full capital, but you can provide the seed capital, and often that’s enough. Your interest secures buy-in from other leaders who put their own money on the table. And since you generated that momentum with your seed capital, you receive all the relevance associated with that project.

  This brings to mind the concept of the first follower,29 described by Derek Sivers as “what transforms a lone nut into a leader.” The first follower is essential to begin a movement and get others on board because he or she gives the leader credibility. Then more adherents join the bandwagon, the more the herd mentality kicks in. IT technologists will not often be the leader, but they can be the first followers to whom the leader will be enduringly grateful.

  SECTION IV.

  SPEAK BLUE

  Chapter 13.

  USIM: Understand and Simplify

  Use cases and USIM

  The technologist’s job is to impact the organization through support and technology. An instance of technology impacting the organization is normally called a use case. (Note that saying “Company X used product Y” is not a use case. Some people call it one, but it’s actually a reference.)

  A technology use case is when we use technology to impact the activities of a business. If you look back at the business model, an activity is a key process required to enable a capability. The use case describes how technology affects that process.

  Use cases and processes are inextricably tied together. You cannot present a use case unless you firmly grasp the underlying process. Over the years, I’ve developed an acronym that helps me with processes: USIM. That stands for Understand, Simplify, Identify, and Measure.

  USIM: Understand

  First is the need to understand the process. In the field of continuous improvement, we use something called the “6Ms” to analyze the parts of a process. These six are:

  • Machines

  • Methods

  • Materials

  • Measurements

  • Mother Nature

  • Manpower

  I have simplified those 6Ms for the IT industry, whittling them down to 4 key components:

  • Actors: the people involved directly in the process

  • Systems: the applications that drive a process.

  • Machines: the end points used in the process (i.e., iPad, laptop, mobile phone, ATM machine, etc.)

  • Key Performance Indicators (KPIs): the measurements of the process

  Using these four components, you can analyze and understand any process. Keeping the four in mind will help you not to forget important aspects of your analysis.

  Value streaming: a German coffee tale

  Let’s talk about coffee again. Earlier, we used coffee to discuss value chaining, which is connecting your day-to-day work to the value your organization delivers to end users. Customers who buy coffee want an intangible benefit, such as the aroma or taste of the coffee. Coffee beans are the raw material that produces the intangible benefit. In between the raw material and intangible benefit is a process: maybe a Keurig or a French Press.

  Let’s stick with this example to introduce the concept of a value stream. Value streaming is examining a process to identify where the value is and how it flows throughout the process.

  I know the name “value stream” is similar to value chain. To keep them straight, remember that a value chain connects the tangible (raw materials) to intangible (the need or feeling) through a process. A value stream is a tool that allows one to see clearly all the critical components of a process and how they fit together. With this tool, the technologist can identify the constraints and opportunities in their process and, most importantly, provide a roadmap to improve that process.

  If you go to a coffee shop, one element of their coffee-making process involves various machines: grinders, brewers, and the like. Many people don’t realize that coffee companies generally do not take care of their own coffee machines. Maintaining coffee machines is not the core of their business—their core is to make great coffee. They outsource what is not core. The coffee company hires a third party to maintain their coffee machines, just like they outsource AC maintenance.

  Let’s call the third party that cares for coffee machines a coffee machine managed service provider (MSP). This MSP manages the machines for retail coffee outlets. The average coffee shop has two or three large machines and a handful of smaller ones. Let’s call the barista, “Helga.” Helga has been working at this shop for a year now and enjoys her job—except when the machines break down.

  Helga is an “actor” in the value stream because she has a role to play. When a coffee machine stops working, Helga tries the old trick of turning it off and turning it on again. If that fails to fix the problem, she calls the MSP, whose value proposition is “Call us—we’ve got your coffee needs covered.”

  Helga dials the number and is connected to a call center. Hans is an “actor” there, a customer service representative. A call-center application drives the phones and the desktops in the call center. Hans talks with Helga, learns that the coffee machine is down, and then tries to solve the problem over the phone with a simple troubleshooting methodology.

  That’s the first part of the process. We have two actors: Helga (the customer) and Hans (the customer services representative). Hans works hard but cannot solve the problem remotely, so he needs to dispatch a repair technician.

  We in IT sometimes get in trouble because we never work through the exact process. In continuous improvement, this is the idea of “going to gemba”. Gemba means “the real place” in Japanese. In
business, gemba is the place where value is created: a construction site, factory floor, or sales floor. When a business problem arises, going to gemba means going to where the problem is. You can’t fix a process from afar. You must understand exactly how it works, up close and personal. Thus, if you are consulting with the MSP, you need to visit the call center and see how it works.

  Hans needs to dispatch a technician. How does he do that? It could be physical communication—pick up a phone and call them. But frequently, MSPs with higher volume automate that process. Hans clicks a button inside the call center application that dispatches field services.

  That call center button prompts the field services application to create a ticket for field services. Heidi is another “actor,” the field services tech. Her job is to receive tickets and go fix machines. She has tools and expertise, but she needs a way to get from here to there. Thus, there’s a fleet management application connected to the field services application, so that Heidi can get a vehicle.

  Additionally, Heidi will need some replacement parts, which are stored in a warehouse. The warehouse staff pick out those parts for Heidi. To effectively manage that system, there’s a warehouse management application that monitors inventory and serves requests to the staff. Heidi gets her vehicle, picks up the needed parts at the warehouse, drives to Helga’s store, and repairs the machine.

  When it comes to business architecture, many people think there are a few applications and thousands of processes. The reality is that there are only a few processes and many applications; we just analyzed the field services process. A process may contain many standard operating procedures (SOPs), but a procedure is not the same as a process. There are only a few processes in any given business.

  Value streaming and business model

  Let’s connect our value stream to the business model. The MSP’s value proposition is “Call us—we’ve got your coffee needs covered.” The MSP supports that value proposition through the capability of repairing broken machines. Capabilities are built from three parts: resources, activities, and partners.

  • Hans, Heidi, the truck, and the applications are internal resources.

  • Field service is an activity, a key process required for that capability.

  • The coffee machine manufacturer is a partner.

  KPIs

  How do we measure success in the field services process? What are the KPIs? Here are a few:

  • Call center repairs. How often can Hans fix the problem over the phone?

  • Dispatch percentage. How frequently does Hans dispatch a technician to repair a machine?

  • Mean time to repair. How long does it take, on average, to repair a machine?

  • First-time repairs. Rework is expensive, so we want Heidi to fix the machine correctly the first time.

  • Mean time of failure of the coffee machines. How frequently do they break?

  • Response time. How much time has elapsed from when Helga calls to when Heidi has finished repairing the machine?

  • Technician accuracy. Did Heidi pick up the right parts before heading out on the job?

  • Technician utilization. What percentage of time are our technicians being utilized vs unbilled time?

  • Vehicle utilization. What percentage of the time are our vehicles in use?

  Additionally, customer satisfaction is one of the most critical measurements. It is a leading indicator with regard to customer retention, because low customer satisfaction means customers are going to leave and higher customer satisfaction means customers will stay. Customer satisfaction is also a lagging indicator with regard to quality, because Helga’s satisfaction tells you how good a job Heidi did.

  My goal here is to model how you can understand how value flows through a process and how that process connects to the business model. Why does this matter? Because you do not want to go low and tinker with the process until you have gone high and grasped it as a whole. Do not allow the interesting trees to block your view of the essential forest.

  USIM: Simplify

  Understand is the first step of USIM. The second is simplify. Here are a few examples of points in the process that could be simplified.

  Data collection: Are we effectively collecting the coffee machine errors inside our own call center application? Is it easy for Hans to mark down what has gone wrong?

  Applications: Do we have too many applications? We may need to rationalize a few, collapsing multiple business logic applications into one.

  Maintenance: Are we following the preventative maintenance schedule for our vehicles? The technicians should know which vehicles are due for which procedures on a given day.

  Distance: How far is Heidi from Helga’s store? Large distances increase transportation costs. Third-party distribution centers are a possible solution.

  Want to know one of the best ways to simplify a process? “Digital transformation” or “digitization,” a current hot topic in the world of IT. The concept of taking something analog and making it digital has been around for a while. Amazon started shipping electronic books for Kindle years ago, for example. These days, everyone is into digitization transformation as a way to leverage technology and stretch each dollar further. Technologists should be at the forefront of enabling our business to make these changes.

  Connecting the unconnected

  About a year and a half ago, I bought a Fitbit Blaze. My Fitbit tracks my steps, records my sleeping hours, monitors my heartbeat, and so on. It connected the fundamental components of my health, so I can look at my Fitbit dashboard and get an idea of how I’m doing holistically.

  Digitization can connect things you might not expect. Have you heard of CaaS? CaaS is typically short for Containers as a Service, but that’s not what I mean. I mean Cow as a Service. Yes, you read that right. Think about milk for a minute. The price of milk varies from country to country, but $3.29 was the average U.S. price for 2016.30 Organic milk costs a few dollars more. For a few people, organic is not enough. They want to know exactly where their milk came from. Capitalists are taking advantage of that desire on some farms in Ireland by putting sensors on cows. In a large production dairy farm, cows are milked by machine. Betsy’s sensor is read each time she is milked, and then the milk is stamped as hers. Whoever signed up to purchase Betsy’s milk receives it soon after, confident that they know exactly where their milk came from. That’s connecting the unconnected.

  How could we apply this to the coffee MSP? Consider the call center. We could integrate the Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) systems into the call center application, such that when Helga calls, Hans gets an automatic popup with her store’s information. He no longer has to ask for her store’s name and location and ID number.

  The coffee machines are a prime target for automation. They are unconnected—let’s connect them. To do that, we need sensors, which are already embedded in the machines. Next, for those sensors to send outbound communication, we need PLCs—programmable logic controllers. We can install those.

  Additionally, we need a network path, a wired or wireless interface inside the copy machines. The machines actually have that too—we just haven’t connected them. This is a fabulous opportunity to connect the unconnected. We could connect the coffee machines and begin securely collecting data from their sensors. That real-time data capture enables us to make real-time decisions.

  Digitization is not new

  Now, there are many marketing terms around digitization and it’s called by many names: “internet of things,” “internet of everything”. In Germany, it’s called Industry 4.0; in Thailand, they call it Thailand 4.0. Despite the complexity, digitization is not new. It actually started with the invention of the transistor in the 1940s. After that, analog started to become digital.

  Take sensors, for example. Sensors ten years ago were the size of a shoebox, cost a fortune, measured just a few things, and spoke proprietary protocols. Today’s sensors are extremel
y tiny, can speak wireless, can speak standardized protocols, cost just cents or a few dollars, and can measure many more things. We can put sensors into anything we want. Your mobile phone has many sensors in it. Some companies have even put sensors into forks! Why? So people can measure how fast they eat; the idea is that they might eat more slowly with feedback and thus lose weight.31 (I have no idea how effective that concept is, but it goes to show you that sensors are everywhere!)

  Think about bandwidth. Today, we have 4G everywhere. Well, 10 years ago in most countries, you had no G. No matter where you live, you probably have a decent mobile connection. On a multi-building campus, where 10 megabit or 100 megabit bandwidth was once standard, these network are fast approaching 10 gigabit bandwidth and all available on wireless. In the data center, 100 or 400 gigabit bandwidths are common. Bandwidth has exploded. Compared to a couple of years ago, the world is connected far more extensively and far better.

  Computer chips are constantly improving. I don’t even know what kind of chip is in my mobile phone. It’s an iPhone, so it must be an Apple Ax or something, but I have no clue what version it is or how fast it is. I actually don’t care—I don’t worry about it because it works. The same is true for my laptop. Computer performance has increased so much that for many applications we don’t have to care anymore. It’s there if we need it.

  Think about storage. Everything used to be hard disk. Now it’s flash storage and it’s much faster. Solid-state drives (SSDs) are everywhere. Form factors have shrunk. The volume we can store has increased exponentially.

  If you look at databases and big data (e.g. Hadoop, SAP HANA, new SQL versions from Microsoft), everything today can be cached in large volumes at real-time speed. 10 years ago, we would have struggled to access this type of data and certainly instant access was impossible. But today, real-time visibility is no longer the future, but fast becoming table stakes.

 

‹ Prev