Metrix Blog

How to integrate Mapping into a Field Service system

2007-10-19T13:45:00.000-05:00

By Tom Bowe
VP of Engineering

I attended an Aberdeen briefing this week highlighting the benefits of location-based service. GPS-tracking and vehicle monitoring are becoming standard business practices in the U.S. field service industry.

The benefits are tangible too…some companies are seeing double-digit cost savings in gas! This is good news for us all, and very timely for Metrix. We recently added a “Show Map” feature to our schedule board so dispatchers can visualize customer locations, technician routes and unassigned jobs (like find nearest tech) using a web-based map tool (like Yahoo or Google Maps).

We evaluated the leading map software vendors and found it to be a fairly arduous task. Although, it took less than 60 minutes to integrate to M5 and verify data was passed back and forth properly, it required 3 weeks to fully assess their respective strengths and weaknesses…especially for technician routing which is non-trivial. So, if you need to incorporate maps into your service system (everyone is doing it), I can save you some time!

Google Maps
Pro - Web service is easy to deploy/integrate and has lots of features including routing
Con – Pricing based on total # of requests and page views

MapPoint
Pro - Easy to integrate into .NET and has lots of features
Con - Full client install makes it harder to deploy, especially if multiple versions are required.

Virtual Earth
Pro - Web service is easy to deploy and easy to integrate with…cool “tiles” and free of charge?
Con – Missing some routing functionality, but supposed to be in new v6 api

MapQuest
Pro - Web service is easy to deploy/integrate and has lots of features including routing
Con - Performance seems slower than the others and doesn’t support mouse wheel zooming

Yahoo Maps
Pro - Web service is easy to deploy/integrate with lots of features and can render using Flash which loads faster than AJAX
Con – Missing some routing functionality, but offers workarounds

If you want to know who we selected and why… give me a call and I’d be happy to share. For more information on market trends and business benefits, the Aberdeen report will be published October 31st.

(Case in point...GPS for NYC taxi cabs...Link)

Tom Bowe

Good Advice from Bill Carollo, an NFL Referee

2007-08-23T17:21:00.000-05:00

By Larry Laux
President and Founder
Yesterday I heard Bill Carollo, veteran NFL referee, talk to my son’s U14 soccer team. As you would expect, a ref that’s had experience in 8 NFL conference championship games, two Super Bowls and a Rose Bowl riveted the attention of the team. His message reminded me that sports, business and life in general can be dealt with successfully. I’d like to remind you, as he did to the team, of things you already know but may be overlooking as you run around at Mach 6.

Teamwork is important. If you are reading this blog you are somehow involved in the service business. It might seem that service is often ‘one-on-one’ as an engineer resolves a problem. But you know that the network of dispatchers, logistics people, supervisors, contract administrators and even vehicle coordinators each could mess up a successful service event, if they don’t do their jobs right. Part of teamwork is doing your job right. Another part is encouraging your teammates in their tasks. Take some time today to encourage one of your teammates, either complimenting them when they do something good, or encouraging them after a mistake. Letting them know what they are doing impacts others is in itself a team positive action.

There is no substitute for hard work. I suppose if your job were pure fun, they wouldn’t have to pay you to do it. But whatever part of your job is the equivalent of ‘hitting the weight room’ should be on your action list. To switch to a rowing metaphor, if someone in the boat is loafing on their oar, we will have a difficult time keeping t he boat going straight. Don’t be that person.

Passion for your team is good. This is much more difficult that it may seem. When you’ve been doing a job for 3, 5, 10 or more years, it is very easy to slip into a comfort zone. But caring, and showing that you care for your customers, your teammates and the issues they have to deal with is a differentiator. So often people would like the magic bullet to lose weight, to get the big bonus or to grab recognition. Being enthusiastic is a pretty magical potion, and it is contagious.

Character matters. Bill defined character as doing the right thing when nobody’s looking. He also spent some time talking about Atlanta Falcon Michael Vick. All of us, all of us have many opportunities every day to choose A or B, to get something done now or leave it for later, to shrug something off as ‘not my job’. And no one makes the right choice every time. It’s human nature! But you should challenge yourself to step it up a notch, even if no one is watching right then. And as Grandma used to say, “Nothing good ever happens away from home after midnight.”

Nothing here is unfamiliar, but you know what? I need reminders every once and a while. Bill Carrolo helped me remember last night, and I hope this blog note helps you in the same way.

Larry Laux

The Discipline of Project Justification - Part 6

2007-07-13T09:27:00.001-05:00

By Tom DeVroy
VP of Sales

Change Management is the process and communication necessary to get your organization prepared for a change and necessary activities to make it happen. Managers usually have a pretty good idea of what they want to accomplish with a new system. They either want to automate processes, become more efficient, make their people more productive, grow the business, improve customer satisfaction, or just attain some other tangible and measureable benchmark that improves business operations and performance. I’m not sure they always communicate this clearly to the troops. The end user community really is interested in one thing, and that is how it will improve their work. How is this new software going to make their life easier?

I always say that to an end user the worst system in the world is the one they currently have....the best system in the world is the one they are looking at...until...it’s time to replace the old one, where it instantly becomes the best system and they usually work hard to make the new one look like the old one. This drives me crazy, but it happens all of the time. Why? Because the lack of vision, and a fear of the unknown.

The great chasm needs a bridge - a good change management plan builds the bridge. They can’t envision how they are going to get from where they are today to where they will be. Panic and fear sets in, and then the only fall back is to a comfort zone of what they are familiar with. See how that old system all of a sudden becomes too attractive. To make matters worse I’ve seen some customers engineer a new contemporary system with best practices and make it look and feel just like the old one they are replacing. What’s the point?

I worked at a consulting company by the name of Bentley Consulting which was later acquired by Technology Solutions. Bill Bentley was an acknowledged leader in Service Management operations. We used a variant of the following graphic to describe the process of change, which still applies today. It looks like this:

Senior management usually has a vision, and it drives overall business goals. This could be new operating methods, improved financials, competitive posturing or whatever, it is going to drive how the business will change to achieve these goals. So the next logical step is to look at the way things are done today and determine if the way you are structured today will facilitate the execution on the vision.

If it can’t, there is a process of re-engineering. This starts by defining the new model. This is usually when people start to inquire into vendors like Metrix. They realize that their existing system(s), for whatever reason, fits the old model, but that model won’t work going forward, so they need a new system that will accommodate the new model. This whole change needs to be communicated to the company, making sure they understand the following:

What are we trying to achieve and why?
What’s wrong with the way we do it today?
How are we going to change and what will it accomplish?
What parts of my job are going to change and how do I fit it to the new model?
How do I fit it to the new model?
What’s the timeframe and expectation of an outcome?
What role will I play in making this happen?
How do we sustain the change?
Can I provide feedback for future improvement?

This step is usually not addressed until after a system and implementation is underway, but if you have some of this information in your hip pocket when you ask for funding you will look like a very prepared project manager.

Just for grins I pinged Wikipedia for their definition of Change Management. I thought this might be useful as it has a few methodology references. I think their definition supports my arguments:

Individual Change Management
An early model of change developed by Kurt Lewin described change as a three-stage process[1]. The first stage he called "unfreezing". It involved overcoming inertia and dismantling the existing "mind set". Defense mechanisms have to be bypassed. In the second stage the change occurs. This is typically a period of confusion and transition. We are aware that the old ways are being challenged but we do not have a clear picture to replace them with yet. The third and final stage he called "refreezing". The new mindset is crystallizing and one's comfort level is returning to previous levels.

Some change theories are based on derivatives of the Kübler-Ross model from Elizabeth Kubler-Ross's book, "On Death and Dying." The stages of Kubler-Ross's model describe the personal and emotional states that a person typically encounters when dealing with loss of a loved one. Derivatives of her model applied in other settings such as the workplace show that similar emotional states are encountered as individuals are confronted with change.

A Formula for Change was developed by Richard Beckhard and David Gleicher and is sometimes referred to as Gleicher's Formula. The Formula illustrates that the combination of organisational dissatisfaction, vision for the future and the possibility of immediate, tactical action must be stronger than the resistance within the organisation in order for meaningful changes to occur.

The ADKAR model for individual change management was developed by Prosci with input from more than 1000 organizations from 59 countries. This model describes five required building blocks for change to be realized successfully on an individual level. The building blocks of the ADKAR Model include:

Awareness – of why the change is needed
Desire – to support and participate in the change
Knowledge – of how to change
Ability – to implement new skills and behaviors
Reinforcement – to sustain the change

Organizational Change Management
Organizational change management includes processes and tools for managing the people side of the change at an organizational level. These tools include a structured approach that can be used to effectively transition groups or organizations through change. When combined with an understanding of individual change management, these tools provide a framework for managing the people side of change.

Other Discipline of Project Justification Posts:

View Part 1 Here
View Part 2 Here
View Part 3 Here
View Part 4 Here
View Part 5 Here

An Eye-Opening Trip to Japan and China

2007-06-29T15:30:00.000-05:00

By Larry Laux
President and Founder

I have just returned from a trip to Tokyo, Beijing and Shanghai. Perhaps you have been fortunate enough to have visited those cities. If not, or if it has been more than 2 years, I can tell you that they are all undergoing building booms. In the Chinese cities, it is a BOOM!

It is almost unbelievable how quickly new buildings are going up. One ‘small’ 40 story building was 1/3 done, and I was told each remaining floor would be completed in 1-2 days per floor.

I saw the ‘Bird’s Nest’ in Beijing, where the opening and closing ceremonies will be held for next summer’s Olympic Games. The Beijing subway has 3 lines now, but by next summer is expected to have six more completed or underway. They completed a 6 lane 100 km ring highway around the city in 2003, and have already completed another 4 lane one, 5-10 km further out.

And Shanghai gives credit to the world’s expo of 2010, but only a fraction of the new construction is directly related to that event.

All of this will impact your company. There is opportunity in these markets. Get there in person if you can and be amazed. Even if you can’t get there, get your products and services there, soon.

A Picture is Worth a Thousand Words

2007-06-20T15:01:00.000-05:00

By Tom Bowe
VP of Product Marketing and Engineering

I love watching high-tech action movies and shows. Many times I’ve seen the “hero” poring through hundreds of high resolution images of the bad guy or instantly pull up a comprehensive background check displaying address, contact and employment history with a big picture of the suspect’s face at the top.

After working at Siebel/Oracle for many years, I realized how difficult these scenarios really were….even with the fastest databases and servers available, enterprise-class software applications take a major speed hit when they try to display large pictures and rich graphics.

Well…things have changed. New technology from Microsoft enables us to embed not only pictures, but also video clips, slide-shows, graphics and other file types and display them immediately on the UI without performance degredation. It’s really cool…valuable too! Want to see it? Ask for a demo of our new app…Metrix 5!

Metrix 5's 'Smokin' User Interface

2007-06-04T13:38:00.000-05:00

By Larry Laux
President and Founder

There’s a ton of things to talk about from our recent Metrix 5 product announcement. Some of you have asked me about it, and I think this blog is a useful vehicle for responding to some questions.

This first set of points relates to the User Interface (UI) of the new product.

If you’re so proud of your UI, why are your screens fuzzy on your website?
Yes, those screen shots are fuzzy, and it’s not a problem with your computer. We intentionally set them up that way. We now have an advantage, a big advantage, against all competitors in our space with our new smokin’ UI (footnote – marketing wouldn’t let me call it smokin’ in the press release, but I have more leeway in the blog).

We decided that legitimate prospective customers can, of course, see the UI in a demonstration. Even that will be given only after we have qualified the prospect and understand that they have a project, that we fit the needs of the projects, etc. But there is no sense in letting the competition see it for free. They have to figure it out on their own – we did.

OK, so what’s so ‘smokin’ hot about it?
Very tricky, ask for the goods without a demo. Well, there are several items that fit the ‘smokin’ category. First, it utilizes the NET 3.0 Windows Presentation Foundation toolset to present content on the screen in a visually appealing, easy-to-look-at way. Transparency, zoom animation, color and other Vista Aero benefits are leveraged so the user can focus on the content, not the UI.

Also, the segments of the screens work together logically. If the user focuses on a particular subset of information on the screen, the software ‘understands’ that they might also want related info, and is ready to make that info available and easy to view.

And the concept of work done recently is used in a common sense way. For example, if a user had certain information on the screen fifteen minutes ago, they can ‘jump back’ to that point very easily. This ‘remembering’ feature should be a big productivity boost, as compared to existing software that makes the user remember (and even worse, type key information in again) to go back to where they were just a few minutes before.

There’s more, but that’s enough to get you started..

Do I have to upgrade all my PCs to utilize the new UI?
You do NOT have to have Vista to use Metrix 5. Of course, to gain maximum benefit of the Aero and other features native to Vista, you need Vista. Another method of running Metrix 5 is directly from your Web browser. And the browser-based version isn’t some scaled down version of the full application - in a browser you’ll see exactly the same UI and have access to all of the same features and functionality you have in the installed version.

So what’s the point?
As with most work we do here at Metrix, the point is either letting you save money, or make more money, or both. This UI should let new users train up more quickly, be more efficient doing their jobs, and provide more accuracy in your data. All of those things should make more money for your company (and as a byproduct, make your employees and customers happier, too).

Tom Bowe, Metrix’s Vice President of Product Marketing and Engineering, and I will be writing more about Metrix 5 over the next weeks and months. As always, your constructive comments and questions are most welcome.

A New Service Blog From an Old Friend

2007-04-24T11:27:00.000-05:00

By Larry Laux
President and Founder

Recently Mark Vigoroso jumped into the world of blogging. For those of you who don't know Mark, he was the Chief Research Officer & SVP of Service Chain Research at the Aberdeen Group for the past five years. During this time we worked with him on several Aberdeen Group and Metrix joint projects. Mark has recently taken on a new role as the Chief Services Strategist at nPhase, and we wish him the best of luck.

His blog, found here, is also planned to cover topics relating to Service Management topics. Welcome, Mark, the water’s fine.

Certainly his self-confidence is not lacking. Taking the url ‘ServiceChainGuru.com’ shows that. Even so, he is a good guy and he does have good background and experience in this field. I’m sure he will have useful and insightful things to say, and I suggest you read his work.

The Discipline of Project Justification - Part 5

2007-04-02T14:32:00.000-05:00

By Tom DeVroy
VP of Sales
Fifth in a multi-part series

My apologies for being absent so long. It’s been a busy time around here at Metrix. I’ve been amiss in my posts. Nonetheless, back to the task at hand. My previous posts had to do with proving to management that your request for money to acquire a new solution would be backed by conclusive evidence of a well-run project.

Up to this point in the series, you’ve created the business case, done your research and explored alternatives. Perhaps you’ve started to build a financial justification and you have adequately explored your options and evaluated your risks. A key variable in deciding to move the project along is the evaluation of the impact on the business from a personnel or resource perspective.

Besides how much ($$$), managers want to know who and how long. I have a prospect I’m dealing with right now in a very similar situation. They have indicated they have the budget, they have established they have the need, but are fearful about having the available resources to dedicate to the project in order to guarantee success. Consequently it appears that they have deferred their decision to move forward.

Most software vendors have a methodology of some kind they follow to assist customers in the implementation of their software. I would argue that any vendor that cannot provide such documentation is likely one not worth doing business with.

Ask the vendor for a straw man proposal for implementation. Here you want to understand:

What does the task list look like?
Who is responsible for what tasks?
What impact does this have on existing processes?
Who is involved from the customer’s staff to work on what tasks?
Are there both IT staff and business representation on the project team?
What is the estimated duration?
Do tasks run concurrently?
Any chance to compress the timeline?

The idea is to get a handle on implementation planning at a high level. This provides some level of comfort that you have thought through the operational impact and affect on existing personnel when you start the project.

Next time around I’ll discuss a similar topic in getting your project plan. Defining what the change management plan is to the management team. In other words, how do we get everyone to buy in to the changes you are about to make.

View Part 1 Here
View Part 2 Here
View Part 3 Here
View Part 4 Here

How often should you get your oil changed?

2007-03-15T09:19:00.000-05:00

By Larry Laux
President and Founder

Seriously, tell me how often you should get the oil in your car changed?

Have you thought of your answer?

Did you answer 5,000 miles? 3,000 miles?

There is a better answer, and it is directly related to the service industry.

The best answer is: you should change your oil when it needs to be changed.

I have been giving this example in speeches for many years. However, until quite recently, only the very top-end cars had the sensors to measure viscosity, particulates and other attributes of the oil to determine if, in fact, it was time for an oil change. One person’s driving habits and location might require an oil change in 2,000 miles, while other situations might not need an oil change for 10,000 miles or more.

But in the absence of those sensors, the car manufacturers go to the least common denominator and recommend an oil change every 3 or 5,000 miles. What a waste!

I think you will see the advancement of such usage monitors in the equipment you service. Already many of our clients servicing imaging equipment have multiple meters on their gear, which provide a crude first step towards usage based service. But really, it’s not the usage, it’s the deviation from tolerances that indicate a need for preventive maintenance.

I’d love to hear comments from any of you that have made progress on equipment that can measure and report its own need for adjustment or preventive maintenance based on self-measurements other than basic usage.

Search is Overrated (UX Best Practices)

2007-02-19T08:57:00.000-06:00

By Tom Bowe
VP of Product Marketing and Engineering

I’m a big fan of Google and use it every day…but, I think search is overrated. Need convincing? Here is a test…go to your favorite search engine (mine is Google) and try to find an image of a professional-looking field technician holding a PDA. I did this yesterday…and after 10+ keyword searches and clicking through 100+ pages…you start getting annoyed! I got sick of hitting “Next” and scrolling to the bottom of each page just to hit “Next” over and over again.

How about a simple “F6” keystroke to go to the next page? I have 10 fast and nimble fingers touching the keyboard vs. 1 slow and aching arm holding the mouse. When you find something…you have to move the mouse and click the mouse…then move and click again to see the image full-size. And then, you either “Save As” (move and click) or go “Back” (move and click…click and move) and start all over. See what I mean?

Yes…I think searching for data is much less satisfying than having the data find me. World-class field service management applications should replace basic searching with intelligent routing, filtering and grouping technology so the right information is displayed when you need it and where you want it…without requiring a user to do anything (ok, maybe one click of the mouse, but that’s it). Search needs to be available to users…for research, reporting, a needle in a haystack, etc., but it should be the exception…not the rule. What do you think?

The Impact of the European Union on Service Operations

2007-02-14T14:29:00.000-06:00

By Larry Laux
President and Founder

At the beginning of the year I was planning on making more blog entries than I have by February. However, things do sometimes get in the way of my bloging – as was the case with my recent business travels to Europe. One of the ideas that I bring back is: The implementation of the European Union (EU) has many significant impacts, mostly positive, on service operations. Two of these are the common currency (Euro) and the relaxation, to the point of elimination, of border/customs issues when transferring parts between offices in the EU.

Metrix customers have educated me, and us, on multi-country service operations. (Remind me sometime to tell you my true story of how the Italian country manager explained the competition’s success against his operation.) Anyway, the countries in Europe operate in a fairly close analogy to regions in the U.S.

Many U.S. organizations divide the U.S. into 4 to 8 regions, depending on the density of their installed base and other operational and logistical issues. Each region (some call them territories, or areas) usually has a manager who is responsible for the service activities, personnel and spares in their ‘turf’. National (or global) service contracts can be a challenging issue that can be discussed in another blog entry.

A common scenario relates to spare parts – a customer in the Southwest region needs a certain part, there are none in the region, but the Midwest region has one. In the past there often would be ‘horse-trading’ as regional managers protected their stock, but more recently inter-region demand is more automated. Of course, as managers’ performance metrics often contain an inventory turns yardstick, proper accounting of the transfer and sale is required.

In Europe, in the past, things were more complicated. The value of the part would need to be converted from, say, Deutschmarks to Francs. This would be especially tricky if the part was sourced not from corporate, but directly by the country manager. Further, the customs drag made it more difficult to move the part from here to there in hours, as today’s SLAs often require.

Both of those issues go away with the EU.

Several other effects are seen as a result. Some organizations have been able to lower overall inventory levels, as they don’t need to ‘keep one of everything in every country’. Also, the need for a service manager in each country has lessened. Some organizations are consolidating into logical service regions in Europe, less constrained by the borders of the countries.

I would not say that they are becoming the United States of Europe. Still, it’s fun to see the changes in the industry and how quickly organizations adapt.

----------------
15 Feb. update - I forgot to mention another interesting issue, not directly relating to the EU. You may know that GPS and vehicle tracking is getting quite some attention in the U.S. But in Germany, I understand that some laws dating from post-WWII prohibit tracking individuals. Do any of you know if that is the case currently, have those laws been changed or is GPS for service people not an option in Germany?

Tom Bowe Joins Metrix

2007-01-11T08:23:00.000-06:00

By Larry Laux
President and Founder

We have a new Vice President of Product Marketing and Engineering! Read the press release here.

Here are some added facts not in the press release. Tom Bowe is an energetic, bright young man whose contributions to Metrix will benefit our customers and our company. I will confess that we were not explicitly looking for a new executive at the time, but when the opportunity knocked on the door, we were ready to open it.

One of the great things about Tom is there is no learning curve for him to climb, regarding the industry. He’s been here, knows the players (and the wanna-be players). He understands the industry jargon and the reasons projects succeed and fail. We won’t have to spend lots of time and effort educating him on those points.

It will take him a little while to learn the details of what our company and our products and our customers are about. But six weeks in, I’d say the process is going better than I expected.

I’ll ask him to write a blog entry before the end of January.

You can e-mail me at llaux@metrix.com or Tom at tbowe@metrix.com.

Best Wishes for the Holidays

2006-12-22T08:26:00.000-06:00

By Larry Laux
President and Founder

Just a very brief note to thank all of you for your readership of the blog, and to share Best Wishes for God’s Blessings to you and your family during the Holiday Season, from all of us at Metrix.

We hope you give, and get, plenty of hugs not only to celebrate the season but to make up for some of the ones you missed during the year, while you were working so hard.

All the Best,

Larry Laux and
Everyone at Metrix LLC

Management Team Buys Metrix

2006-12-04T08:51:00.000-06:00

By Larry Laux
President and Founder

My partners Tom DeVroy (VP Sales), Pat Liegel (CFO) and I have completed a friendly Management Buy-Out of Metrix, Inc.

We formed a new Limited Liability Company (LLC) here in Wisconsin and used it to acquire most of the assets and liabilities of Metrix, Inc. including the software rights, support contracts, websites and the name itself.

So as of the end of October, we are the owners and management team of Metrix LLC.

As you might expect, that activity has taken a good bit of time and effort to complete. It is the main reason why I have been delinquent in making a new blog entry.

For current and potential clients, this is something of a non-event. All of the people from Inc. have been offered and accepted employment with Metrix LLC, doing the same jobs as before. All of the telephone numbers, addresses and contacts remain the same.

This management buyout is only the beginning of an exciting time for Metrix, our clients, employees and partners. For example, we will be updating our website and brand by the end of the year and making other significant announcements in the weeks and months ahead. It’s all part of the new Metrix and the advances we are making in products, personnel and services.

So why did we do it?

The simple answer is the most accurate – we see a very strong, positive future for Metrix, and we felt that it could be best achieved with a simpler ownership structure.

That we would invest our own money into Metrix makes a very strong statement to our confidence in and commitment to this marketplace.

Leave your comments here, or e-mail us at llaux@metrix.com or tdevroy@metrix.com or pliegel@metrix.com.

Thanks for having confidence in us. Stay tuned.

The Discipline of Project Justification - Part 4

2006-11-29T09:30:00.000-06:00

By Tom DeVroy
VP of Sales
Fourth in a multi-part series

You have defined the rationale for your project. At some level you have defined or intuitively understand your requirements. You may have spent analysis time defining what needs to be changed in your business. Now you have to ask yourself: “what happens if things go bump in the night?”

Every project has some level of anticipated returns; likewise, every project has risks. Take a little time to think about the unexpected. What are your project assumptions and risks? These should get played back to your vendors during the selection and evaluation process.

Some possible examples of risk points include: resource availability, business climate change, management expectations, unrealistic timelines, new product announcements, training issues and personnel issues. Obviously these factors are magnified by the scope of the project - the smaller the project, generally the smaller the risk. Likewise, the larger the project, and the greater the complexity, the greater the risk of the project will be.

For these reasons, you should issue an RFP or tender an offer to vendors and make sure you articulate your constraints. It will help you evaluate who can work with you. This might include a proof of concept to reduce the uncertainties, or asking the vendor for more resources during implementation to get around resource shortages. Maybe you want to go slow in anticipation of growing your business while you are implementing.

The same applies with assumptions. An assumption could be simple, such as a place for a consultant to reside while on-site, or complicated, such as a move of location in the middle of the implementation. Perhaps there is no IT infrastructure and the vendor has to provide hosting services.

You can never predict the future and hindsight is 20/20, but try to identify your risk points and assumptions so you can manage around them. When you go for final budget approval, or project funding, it will help to sell your business case if you can call these out in some level of detail and account for their potential costs up front.

The goal here is to not have surprises and gotcha’s post sale. Next time we’ll talk about project timeline, milestones, and resource or skill sets in an implementation project.

View Part 1 Here
View Part 2 Here
View Part 3 Here
View Part 5 Here

The Discipline of Project Justification - Part 3

2006-10-23T11:49:00.000-05:00

Third in a multi-part series
By Tom DeVroy
VP of Sales

I started this series discussing some of the steps I’d recommend to a project team when trying to justify a project to management. The second part of the series dealt with the definition of the business case. In this post I’d like to discuss a solution scenario, which is a situation where you have management understanding that there is problem, perhaps they have painted a vision or made a vision statement, and now they’d like to hear your ideas for potential solutions. Not that they are looking for a vendor recommendation or the definition of what the internal costs might be, but are simply interested in hearing more about their options in a way the demonstrates you understand what is trying to be achieved.

This requires some research and often times a good deal of work. You have already spent a long time thinking about what the business problems are that you want to fix. This could be inefficiency in your operation, dual data entry, lack of visibility to service levels during a service process, missed revenue opportunities, or whatever the case may be. Understanding your business problems that need to be fixed should drive a whole new set of business requirements.

What’s the Current State of your Company?
These requirements reflect the necessity of your specific business, as well as those requirements necessary to address your future model. Consultants refer to this as current and future state. It would make sense that most people know their current state but I frequently find that this isn’t the case. Often when we ask prospects about their current business process we tend to get more questions, blank stares, and referrals to other departments or individuals. It is very hard to derive the benefit of a new automation project when you can’t determine the impact on your current business.

Take the time to define your current operating model. If time or resource demands are too great to perform an adequate analysis internally, hire a consultant - they are experts at performing these assessments. This, however, is a task best performed internally because it requires a good deal of interdepartmental cooperation and communication.

The Present will define the Future
When completed you need to take the documentation to determine the future state of your company (the state it will be in after the problems are fixed). This future state ought to align with the vision of management. Once again, if you have a problem thinking outside the box, hire some external industry expertise, or use the change process to force this new model of thinking. It’s ideal to do this work before you start a solution search but it’s not always practical. Do the best you can to at least identify what it is in your current state that you want to change or fix. Between the current state and the future state this should drive your requirements.

Draft your requirements against those processes in the current model that you want and need to bring forward, as well as those requirements necessary to meet your future state. A good example would be a company that closes out their service calls on paper. This causes delays in billing, disputed invoices, and extends their AR days outstanding. To remedy the problem they would like to automate this function through mobile automation for their field people. After this is clearly articulated, management will want to know their options.

Make Sure that Management is Onboard
Speaking of management, get approval and sign-off along the way. Have them review the current state documents and have them approve the drafted changes in the future state. They should be well aware of these changes seeing that they are the ones that ought to be driving the changes.

The research in the solution definition should include the technology choices, different vendors, preliminary budgets, and so forth. Once again, get some management approval on the technology and the vendor alternatives. Managers may have strong preferences to particular technologies - or they may not care as long as the functionality meets the needs of the business. Whatever their opinion, it’s always better to determine this up front.

Don’t Blow it on an Unrealistic Budget
There’s nothing worse than spending a long time on a project only to find out that there is absolutely no money to fund it. So it’s important to make sure that your budget estimates are realistic. Finally, get your potential vendor alternatives approved in advance. Managers and executives may have had past dealings with a vendor that drives their preferences. Once again, better to understand these preferences up front.

I find that the selling process for Metrix is often a validation process for our prospects. They go through a buying process to validate a decision that was tentatively made prior to vendor evaluation. It pays to do as much up front research as possible, getting buy-in and approval along the way.

In the next post I’ll discuss how you might want to define project assumptions and potential risks, as well as rewards.

View Part 1 Here
View Part 2 Here
View Part 4 Here
View Part 5 Here

What is good software, anyway?

2006-10-13T15:23:00.000-05:00

By Larry Laux
President and Founder

That might seem like a silly question coming from the CEO of a software company, but I’ve been asking that question of myself lately. I’ll share some of my answers, and some related questions and answers, in this and in some upcoming blog entries.

To be able to answer the question, I need to re-state and frame my question more tightly: ‘What is good business application software?’ To begin with, what pieces make up business application software. Then, what makes those pieces ‘good’?
Here is a short list of general attributes of business application software:

It has to perform the business function it was designed to perform – print payables checks, track field inventory, whatever.

I am not convinced that there can be ‘too much’ business capability. But I do agree that software can be hard to understand and follow what it’s doing (which can safely be called ‘bad’). Also, if users don’t want to use a feature, they should be able to easily ‘turn it off’ or otherwise avoid it without being forced to plow through unwanted stuff.

It needs to play well with other systems. For example, a scheduling package must easily take in data from the system storing all of the service calls, perform the magic of optimization, and send the answer(s) back in an acceptable format. This ‘data mapping’ and integration of information between systems can easily ‘blow up’ a project. More about this in a future blog entry.

The software must have good hygiene factors. Among these are:

Runs fast enough, short response times.
Is secure in its handling of data, especially sensitive data.
Can reasonably grow with your organization without degrading performance.
Is built in an acceptable or better technology.

The user interface is another piece of the overall system. I am still not convinced that any software is or can be intuitive. Sorry, Mac users, I don’t buy it. But I absolutely think it can be conventional, and MUST be consistent. Further, if it can be easily adjusted to the specific business process of the users, that is a significant advantage.

It’s interesting that some of these are subjective – what is ‘fast enough’ for some situations may be totally unacceptable in others. I expect, though, that a small group of smart people in your company could get together and develop a list of wants and needs from this very high level list of attributes.

But what makes application software good?

Partly, good-ness is contained in how the above items are achieved. A hands-on trial can help determine if you think the user interface is ‘good’.

I would say that if a software package were to be judged ‘good’ in three, or all four of these categories, it would be ‘good software’. But I think there are more attributes that a software application can have. With them, a ‘good’ software package can be ‘very good’ or ‘great'. I will try to get to those in a blog entry next week.

Let me leave you with one closing thought.

Software vendors especially, but sometime also buyers, get wandering among the trees of features, functions and sizzle and lose sight of the forest.

I think the number one, most important, gotta-have from a software application is – USING THE SOFTWARE MAKES MORE MONEY FOR YOUR COMPANY. Everything else is fluff.

I completed the Milwaukee Lakefront Marathon

2006-10-02T09:15:00.000-05:00

By Larry Laux
President and Founder

Yesterday I joined 2500 other marathoners and started the 26.2 mile journey. As a first time marathoner, I really didn’t know if I could finish, or even what to really expect. The longest distance I had ever gone previously was 11 miles.

I had built a plan based on Galloway’s training method – run, run, walk. I would run for two time periods, then walk for one, right from the first mile. I felt remarkably good for the first 3 ½ hours.

We were very fortunate to have an excellent day for the race. The sky was cloudless all day, and very light winds. Temperatures at the start were 50 or so, and rose to the upper 60’s by early afternoon.

As the saying goes, I ‘bonked’ a bit around mile 19 or so. My legs started feeling pretty heavy. I had been taking my ‘goo’ (a carbohydrate gel designed to give a controlled fast-acting energy release without the crash) about every hour. By the way, they try to make it palatable (‘apple cinnamon’, ‘raspberry’,’vanilla bean’) but overall it’s pretty disgusting. Still, finishing was not certain.

Somewhere in there I switched from run, run, walk to run, walk, run, walk. In Mile 23 as I hit the lakefront, I was pretty sure I would finish. My support crew (my wife Nina) had been providing me with support and assistance throughout the race. She was incredibly helpful and patient.

How did I get this idea? Well, I turned 50 this year, and my Mom (she is SO cute) sent me $50. Now, what can I do with $50 that will be memorable?

Two words: “Entry Fee”.

So, now I can tick the “Did a marathon” box on my life accomplishments list. I doubt that I will do another one. And you don’t have to be concerned about me being too boastful of this feat. Metrix’ VP of Sales, Tom DeVroy has completed an Ironman Triathlon – where you swim for 2+ miles, ride a bike for 120 miles THEN run a full marathon. Worse yet, on his day the weather was in the 90’s.

He wins bragging rights.

p.s. if you’re really curious about my final time, click here and enter Larry Laux in the name box.

Quality Assurance in Software (It CAN be done!)

2006-09-29T15:04:00.000-05:00

By Larry Laux
President and Founder

I spent an hour today with the Metrix person in charge of Quality Assurance in our products. It was a most pleasant, and interesting, conversation. I’ll share some of it with you. One of the basic points of understanding is: all software has bugs. Ours, Microsoft’s, SAP’s, the video game you picked up for your kids – all software. Some bugs are known, some are not. And some that are known get reclassified as ‘features’(that’s a topic for a separate essay). So given that, what can and should be done?

Our guru walked me through the Metrix QA framework. At a very high level, he explained that automated testing, where pre-formatted inputs of data and simulated keystrokes are fed in to the system via a testing program, can reasonably exercise 75 to 80% of the code. The output of these exercises are compared (also automated) to a pre-built expected outcome reference file. When they match, life is good; the programs are functioning as designed. When they don’t match, something is wrong. An error exception report is generated and routed to, among others, the QA manager for further investigation.

So far, so good.

Manual test scripts are another piece of the plan. They are step-by-step instructions that are taken by a person at a device or workstation, using the system. They can visually observe the reaction of the system as the keys are hit, and record results. This type of testing is great for catching items that aren’t bugs per se, but may make the system annoying or difficult to use. An example – when a user hits backspace on a field on a web page, and the page fully resets and clears all of the values already entered. This is annoying (has it happened to you?) but the type of thing that is not easily built in to automated test scripts.

These manual test scripts should cover 20 to 25% of the system, making sure that each function type (add, delete, inquire, report etc.) is represented, as well as key functions.

A third component is called scenario testing. This may be driven by a particular client need. For example, we know that Metrix client ‘X’ uses the Repair Center module in a certain un-typical way. We can have them provide us with a scenario, or set of testing scripts, which can be performed prior to any release or upgrade patch application to their environment. This technique would test 10 - 15% of the overall system, typically. (Percentages add up to more than 100% because of overlap; some items get tested in multiple ways.)

Scenario testing is also useful for exercising integrations.

Finally, perhaps the most ‘fun’ testing is ad-hoc. This is usually done by two types of individual: 1) a very, very knowledgeable person who knows the system well and thus knows where the fragile parts are; and 2) a very novice user that might put funny characters in a date field, because they aren’t sure what the software is looking for. Both of these testers look at their tasks as a game as they try to ‘out-smart’ the programs (and programmers). This process covers 10 – 15% of the system, and is looked at as a statistical proof step in the quality assurance process.

Our conversation covered many other points but I thought these items were interesting enough in general to share. Does your group engage in a QA process that is similar to Metrix’? If you have feedback to share, please leave a comment, thanks.

The Discipline of Project Justification - Part 2

2006-09-22T14:56:00.000-05:00

Second in a multi-Part Series
By Tom DeVroy
VP of Sales

In the last post I discussed a methodology for justifying a capital project to management. My proposition here is that there is a process involved and some discipline required for a successful conclusion. In this post I'd like to address the first requirement of project justification.

The Pain Statement
The first step is defining the problem you are trying to address. If you can't articulate the problem you definitely can't make a case for the money to fix what (apparently) isn't broke. There isn't any reason to buy a system, or acquire new hardware, if you can't clearly indicate the pain caused by the current status quo. The definition of your problem is what I like to call the "pain statement". The bigger the pain statement is, the easier it will be to ask for the financial means to fix it.

For example, if your business consistently missed customer expectations in customer service, this would drive down customer satisfaction and cause you to miss out on new business opportunities for product sales. This pain statement, although intuitive at this point can probably be backed by financial justification later down the road. Pain statements don't always have to be so complete though.

Another example could be something along these lines: Our current system is old, it runs on hardware no longer supported and much of the technology is aging. It is forcing us to not change anything. First, this makes us very vulnerable to catastrophic failure, and secondly, this forces us to remain in a status quo for operating procedures and business processes. Our infrastructure needs updating or we run the risk of not being able to support our own environment. Once again, the pain is intuitive and it opens the door for further justification down the road.

The nature of the problem probably will dictate who will fund the solution to the problem. My first example is an operational issue. The solution to the problem probably comes out of a departmental budget within Service Operations. The second problem is likely an IT problem that should be funded from the IT department, although both problems affect the business directly.

The Hypothesis
After creating a pain statement a hypothesis should be developed for solving the problem. The hypothesis defines a possible outcome and perhaps defines a potential solution. Although the person that develops the hypothesis should be careful not to be too forthcoming with a solution. This might imply that the author has an agenda and has pre-determined an outcome before adequate research has been performed.

If we go back to the first example, a proposed hypothesis might be that we look for an integration strategy or solution that combines our contract SLA's, our customer master, and our problem tracking system. We can then have visibility between the customer contract commitment, their currently reported problem, and what levels of service we owe them to resolve their problem. Notice that I don't suggest a "new" system, although such a suggestion might be the final solution.

Further into the evaluation, you likely will be asked for one or more alternatives that address a solution to the problem, to financially justify it, and to create a coherent business case. We'll save these topics for future posts. Next post, establishing the business case.

View Part 1 Here
View Part 3 Here
View Part 4 Here
View Part 5 Here

Mobile + Technician + Linked to Information

2006-09-15T13:18:00.000-05:00

By Larry Laux
President and Founder

In 1991 a national service manager with Du-Pont medical products approached us with a classic service problem. His service engineers were responsible for both break/fix service and for preventive maintenance service on their products. He was wrestling with this issue - if an engineer is sent to St. Michael’s Hospital on a repair call, wouldn’t it be great if he could also easily check to see if any preventative maintenance was due? If one was due, he could perform that work right then, while he was on site already for the repair call. Saving even a few additional trips per week would have a big cost benefit.

It was this scenario that lead to Mobile Techlink being born. It seems almost laughable in retrospect, but the state of the art in portable computing at the time was the HP 110. That diskless, clam-shell PC had 640 Kilobytes (Kilobytes, not Megabytes) of RAM. In that space we had to store the data, the operating system and the Mobile Techlink application. Can you say ‘efficient programming’?

While developing Mobile Techlink, data synchronization was one of the most difficult problems we had to deal with. It took years to work out such questions as "Who has the right to update what data?" and "What if the same data element is updated by two different people on two different computers at the same time?"

Since there was no wireless or broadband to speak of back then, connection was via phone lines. Some of the engineers used acoustic couplers (you are officially old if you remember them). Even though the data was, generally, only updated once a day, the benefit of current data available when the engineer needed it was huge.

Some of the technology has improved - handhelds are much more robust and laptops (with much more RAM than 640K) are standard issue. In addition, wireless and broadband have become cost-effective and widely available, aiding the access to data while in the field. Some technologies have arrived that weren’t possible then - signature capture is one example.

But all of this technology has not made the Field Service Engineer as connected as I would have expected. I think part of the reason is the devices themselves - is a cell phone a reasonable form factor? Is a full keypad needed? (I for one am glad to be past the Graffiti® stage.) Will there ever be a truly usable tablet device?

Mea Culpa, software must also take some of the blame. It still has room for improvements on features, speed, configurability and usability (and we’ve re-written Mobile Techlink four times in the last 15 years to tackle many of these). I think we are much better than we were, but still not quite where we need to be (but - shameless plug - we are pretty proud of our most recent release of Mobile Techlink).

And ten years from now, will the equipment be contacting the engineers devices directly? I’m not sure I’m mentally prepared for my washing machine to speak up and tell me it has logged a service call for itself and the tech will be here Tuesday at 8:15. Although, now that I type it, if it could send me an e-mail instead of talking...

Easier Service Through Color Coding

2006-08-25T12:12:00.001-05:00

By Larry Laux
President and Founder

I’ve been around the service industry a long time, over 25 years. I have been able to see hundreds of service operations, servicing a wide, wide variety of products - blood analyzers, medical imaging equipment, overhead doors, coin counting machines, silicon wafer producing machines, copiers and many others.

I am amazed and impressed at the amount of user-service that is in place today vs. even ten years ago. Hewlett-Packard was an early winner on this front, putting much of the print mechanism in the toner cartridge and having users ‘do it themselves’. It really surprises me how willing consumers are to open their PCs and put in a new disk drive.

So here’s my question.

Why don’t manufacturers color code their components?

In some industries there is a strong trend in product design to introduce modularity, or easily swapped component structure, into the device. This is so the service person (or the users themselves) can relatively easily swap out a bad part, insert a new one and be back up and running.

So, if there are five major components inside an imaging machine, why not make one tan, one blue, one orange . . . you get the idea. I think a company could REALLY advance on the user self-service front. Or if self-service is not on the table, technicians could be revenue producing sooner and with less training.

Have you ever seen a product with color-coded components?

Attacking Service Problems - The Fun Way

2006-08-23T10:08:00.000-05:00

By Larry Laux
President and Founder

Some of the problems in service are profound, some are trivial.

Some can be attacked in a fun way.

Several years ago, a Metrix client that services hospital and lab equipment was looking for a way to grow revenues. Their U.S. Director of service came up with a clever idea that worked well and I’ll share it with you.

They had a good business book in both service contracts and in break/fix. As usual, margins were better on the contracts side. Other than waiting for sales to sell more new products, how could they expand their revenue opportunity in contracts?

The national director of service rolled out a program to the service engineers. "Find a device" he called it. Whenever an engineer went on site for a call, they were to ask and look for other devices that they could service, but that weren’t in their installed base (they could refer to their laptops to see the known installed base at the site). They would then report back models (in some cases serial IDs) and they received ‘credit points’ based on certain brands, models etc. The manager had pre-set values for different types of products, higher value for some, not so much for others.

At the end of each month, point totals were published, and after the program wound up (4 months as I remember), points could be exchanged for marketing stuff (caps, shirts, jackets) with the company logo.

It actually turned into a competition of sorts for some of the field folks, to see who could claim bragging rights.

As a result a wide pool of new service contract prospects were developed. Of course, they were all pre-qualified as each site was already an existing client. They just needed to market to them to add these other products to a service agreement.

It worked well for them. Maybe your company can use a similar program.

Have fun!

The Discipline of Project Justification

2006-08-18T16:32:00.000-05:00

A multi-part series
By Tom DeVroy
VP of Sales

As Metrix launches this blog, I’ve been asked to contribute on topics that might be relevant to our target markets and customer installed base.

As VP-Sales I see a lot of prospects and customers make an effort to quantify the tangible business benefit of a service systems project. For that matter any significant project that impacts their business. This might include field automation, back office processing, integration, new field devices, communications, new service initiatives, etc. Often times the person who is the project lead does all of the homework, might establish good vendor relations, go through a thorough evaluation, and fall short of selling the final vision to management. Several variables, of equal weight need to be considered, in ‘selling’ a project to management.

Most management is interested in what impact the project is going to have on the business. What resources are involved, how long will it take, what risks do I face, and what can I expect at the conclusion of a successful project. How is this project going to either make me money, or save me costs.

This multi-part series will comment on some of these considerations. I’d like to organize the series as follows:

- Define the problem and build the hypothesis
- Establish the business case
- Articulate the solution
- Define the risks and assumption
- Establish the resource requirements and timeline
- Define the change management implications
- Build a narrative
- Separate hard and soft savings
- Pick a modeling tool
- Build a realistic financial model
- Define the tracking and reporting mechanisms

I’d really like these posts to focus on how a project lead sells a project to management. Even if management intuitively knows they have a problem, or that a better mousetrap can be designed, they need to have some confidence that what they are investing in will return some level of expectation. For instance, when you buy a new car you might go through the same kind of analysis. I like to use cars and houses as samples of buying patterns.

When you go to buy a car you usually will run through the following mental machinations. Do I really need this? For what? When? How much can I afford? What image will my car reflect on my family? These simple questions start to drive solutions - car types, models, and makes. But this is a long way from actually signing a deal with the sales guy.

In the next post I’m going to pose the question of building the hypothesis. If you have ideas or suggestions please share them with me.

View Part 2 Here
View Part 3 Here
View Part 4 Here
View Part 5 Here

Unique Links in your Service Chain

2006-08-18T16:25:00.000-05:00

By Larry Laux
President and Founder

Having been in the business of providing software for service organizations for 25 years, I would say that all service organizations overlap business process for 50% to 70% of their activities.
When the product doesn't work, someone needs to do something: go there & fix it, or send the product back, or send a part for the user to fix it, etc. Doesn't matter if the product is a medical imaging device, a gaming machine, a piece of computer equipment or a door. And at the simplest level, who went, what did they do, can we send a bill or collect money are the building blocks of a service process. Such are the links in the Service Chain that most service organizations would easily recognize.

And what about the balance of activities, the 30% to 50% that does not overlap?

Those activities are the links in the Service Chain that are the unique bits of a service operation. Sometimes they arise from the particular properties of the equipment being serviced. An example would be gear containing radioactive materials, which require special tracking and handling. Government regulations (think medical devices) require certain process steps not needed in refrigeration repairs. The customers may be the cause of specialized service chain process (again, government as an example requiring special security clearance for access).

Even if you see the product you are servicing as a commodity, the unique bits might be how you differentiate your service from the competition. This 'special sauce' makes your service chain unique and, we expect, more valuable.

So here are a few questions to ponder regarding your service chain:

Do you understand the basic links in your service chain that are the same or very similar to your competition?

Can you identify at least two unique links or processes that are a) repeated frequently enough to be significant and b) are an opportunity to make money?

Are you making money on those processes?