Help, my data’s all over the place!

One of the main problems with any corporate IT project is getting all the data to the system. Data is generated in a multitude of systems and stored in just as many places and formats. Some data gets duplicated and/or transformed before stored in other systems. Rarely do even corporate IT departments know what is stored, where and in what format. Sometimes data is stored and nobody seems to know what it means… 

I visited a major bank recently and just for calculating their portfolio risks, they estimated some 7,000 spreadsheets were being used – I’d hate to be in the shoes of their risk officer (and I’d also be scared to be a shareholder)!

The traditional approach for gathering data for a specific usage has been to set up queries to extract data from source systems in a pre-defined format. This approach is not only long, it is also prone to errors and not very flexible (if the source data changes, adaptations need to be made to the integration). New technologies allow for the creation of data lakes (unstructured data storage) however. This is much faster and retains full flexibility on all the data.

The first result of grouping all (or as much as possible) data is to create visibility. In our case: how many delays, how many breakdown, which parts are causing most problems, etc. The capability to make problems visible allows huge savings (a major European railroad reported that such a project saved them 8% on their maintenance costs) because it allows people to make better decisions, avoids ‘flying blind’ or even avoids abuse (there’s no more hiding).

Once all the data is centrally accessible, projects such as predictive analytics can be launched with less effort. Provided the data centralization environment is up to the task, it should be flexible enough to allow for a stepped approach; i.e. just bringing together all corporate data first (ERP, EAM, CRM, planning,…) and adding equipment sensor data at a later stage. Those familiar with the traditional approach know how painful this can be as it would essentially require the definition of a new data structure. This is avoided by the big data approach.

What’s the conclusion? Don’t be put off any longer by data integration pains; choosing the right technology and approach allows for rapid, performant, flexible and appropriate deployment of a data storage architecture which can be the foundation of your predictive analytics project.

Doing so will allow you to optimise:

  • visibility; before setting off on any data analytics project, make sure you have optimal visibility over existing data (volume, quality, etc.)
  • project efficiency: the stepped approach delivers value faster 
  • consistency: data centralisation lowers IT landscape dependencies
  • flexibility/adaptivity: the tiered approach allows for application adaptation to changing requirements without requiring re-integration
  • functionality: new functions can be developed and rolled out gradually while retaining a single (centralised) data source

Faster,  incremental results with lower project risk leads to higher NPV (Net Present Value) – the only measure that should really matter!

A Texan’s guide to Predictive Maintenance

Having lived in Texas I was always amused by the sayings. Most of the time they were polite and humorous ways to flag stupidity or make a point. So with that I will use some popular sayings to relay some best practices in a Predictive Maintenance project.

All hat and no cattle

A lot of companies start their predictive maintenance efforts with their current big iron vendors. I shake my head every time an IBM commercial comes on. You can’t buy a smarter planet or Watson but you sure can spend a lot of money on consultants who know very little about your business and try to build it on your dime. If you want to outsource your data center or fund a big consulting engagement then call a big iron company. If you want to get results quickly then find a company who has some industry experience in improving maintenance and is willing to spend some time with you understanding the business. At the very least include a few companies in your initial evaluation. You will learn more and be able to sort the fact from fiction.

When all you have is a hammer every thing looks like a nail.

This saying was popularized by the psychologist, Abraham Maslow, in the 60’s. Everyone has heard it. If you hire a consulting or outsourcing company to help with your predict analytics project don’t be surprised when the answer is “we need to study this more and bring in more people”. When you hire a company who specializes in cloud infrastructure or building data lakes to help with predictive analytics don’t be surprised when they tell you “you need a data lake first.” Nothing wrong with spending a lot of money on consulting or building a data lake it just does little to solve your maintenance problems. When your problem is improving maintenance you need a solution designed to improve maintenance. When you start a project for Predictive Maintenance make the project about maintenance results, which is what my next saying is about.

“Be careful how you make your bed because you have to sleep in it.”

This is an old saying and it is something my grandmother actually said to me as I was leaving home after graduating college. My reaction was “yeah whatever grandma” but in hindsight I realize that my grandmother gave me a mighty snippet of southern country wisdom. In projects involving predictive analytics this should be the tagline. A lot of projects go well but some don’t. The difference is how the project is planned. It’s called Predictive Maintenance – the word “predictive” is an adjective to the noun “maintenance”.   The subject is maintenance! Make the project about maintenance. If you focus on what predictive analytics can do for your maintenance processes you are off to a good start. If you focus on predictive analytics as the subject you are off to my next saying:

A long road to a small house

This one simply means a lot of work for nothing. If you ask a data scientist what success means they will start off on algorithms, prediction accuracy, recall rates, etc. If you ask a maintenance manager what success means he or she will answer in availability or return on asset. What are the metrics for your predictive maintenance project – if you hear words like precision, recall, accuracy you are on a “long road to a small house”. Let me give you an example.  A predictive model has been built to flag a problem that will cause a locomotive to fail but it is only correct one out of ten times. The data scientist would likely dismiss this as a failure. However if you go to the maintenance manager and tell him to perform this ten minute test on certain locomotives the next time they come in for planned maintenance and that for every ten you check you will prevent one catastrophic line of road failure, watch him smile. That is a big win or as they say in Texas, In high cotton.

What makes a successful UI for a startup?

No one really knows… until they have some real customers and real users.

Friends reach out for help when joining a new early stage startup, or looking for ideas on what it would take to build a UI for a startup they are thinking about starting.  This is some of the info I give them, so I figured this might help others to.  Is this “best practices”, or “industry standards”? No, but might lead you to the path for the right answer.

From a UI Developer’s perspective, let’s separate what parts the UI is normally responsible for. Asinthecity’s blog post diagram, shown below helps illustrates this.

ui vs ux

As you see, the UI is the glue that connects all the work that everyone in the team has contributed. From the back end team, which usually gets very little credit but gets all the blame when something is not working, to the stakeholders that have pushed this from an idea to a product.

Startups go through many stages, that’s a reality. Below are some typical stages startups go through:


What does this mean for UI Development?

  • START – An idea, from thought or paper, to something people can interact with using the core product
  • SEE WHAT STICKS – Enhancements to help sales close the deal (will not go into details, but a lot of throw away development)
  • CLOSE DEAL – The first couple of customers have say on additional product features (probably will not have anything to do with your core product)
  • STABILIZE – Go back, clean up code, and implement some backlog features
  • FUTURE PROOF – Start transitioning to long term plans for better maintenance and enhancements

Developers want to build a successful UI for their startup. They want potential customers to “want” to use the product, not “have” to use it. With that in mind, I am going to walk you through some scenarios and possible solutions to help make this happen.

Let’s put our UI Development hat on and work on a project from start to end.

Start Project


If you have a UX Designer on your team, good for you. Skip this section since it’s their responsibility. If not, then be mindful in this stage. These are the fundamentals that could cause a domino effect delaying rollout and transitions to the different product stages. How? At times, startups get desperate, shift quickly and forget about the companies core product or offering.

Before you even start talking colors, layout, etc., take a step back and make sure you have at least these questions answered.

Fundamentals before starting ui development

Will we be building a Public or Enterprise type of app (there are others, but sticking to these 2 examples for now).

Public vs Enterprise type of app


Let’s Get Started

So we join a startup that is revolutionizing the way products are sold and delivered. Additionally, they get a ton of information and claim they can analyze and help with reports. At the moment, all this will be displayed on a website.

  • Core Product = Custom software that makes it easier to sell, everything from Amazon, eBay, and their own online stores.
  • What problem does it solve = Greater Sales, easier to maintain, robust tracking and analytics
  • Target Audience = Large Retail Companies (ENTERPRISE)

It is your first day on the job and they say “We are doing a pitch to Toys’ R Us at the end of the month, do you think you can have something done by then?”  That’s less than 2 weeks away.  Welcome to the Startup world!

Here is some additional information that was gathered:

  • They have been presenting power point slides with mockups
  • There is a lot of interest on the Core Product
  • Some potential customers like the widgets but prefer they be organized differently
  • Some widgets have not even been finalized because backend is still working on them

Not perfect, but you can work with this.

Based on the information gathered some of the requirements consists of:

  • Get a fundamental UI to display data decently
  • Many widgets (tables, charts, etc.) that will be used throughout the UI, just not sure where they will be in each view
  • Need the ability to rollout new features quickly (widgets) and add them to the different views
  • There is an existing API that can provide all the information needed


Technology Stack

Thought only back end dealt with technology stacks? Guess again. Below are some front end frameworks and tools used to help with development.

Popular Front End Technology Stacks

Chances are you will end up using 3 or more of the above for your development.

A CSS Framework, a Javascript Framework, and a build system.

Why? Many of the requirements and problems can be addressed by using a Javascript Framework.  To start getting feedback ASAP we utilize a CSS Framework and to help with development a Javascript Build System.

Choose wisely.  All these tools are great, but each have their pros and cons.

Some friendly advice.

  • Choose tools that you either know or can pick up quickly
  • Make sure you have sources to get help
  • If you need to bring in outside help or hire new team members, there are nearby sources.  (User groups are a great source)

For the purpose of this exercise we are going with:

UI Blog post


  • Angular, a HTML5/JS framework, for its modularity but specifically for us, directives (widgets), services (api calls) and user forums
  • Bootstrap, a CSS framework, because of my experience and comfort level
  • Sass to set variables like company colors and re-use them in the different files
  • Grunt as the build tool, local web server and misc. tasks (deploy, build, concat)
  • Bower for dependency management

In the next blog post, we will start to write some code and create some views leveraging the tools we have chosen to go with.

The many faces of maintenance

When referring to maintenance, people often forget to distinguish between different kinds of maintenance. Yet, correctly separating each kind is a pre-requisity for a well-managed business.

The first kind of maintenance is one we all know from taking our cars to the garage for a time- (i.e. annual) or distance-(i.e. every 10,000 miles) based check. During these routine maintenance, several parts, such as oil filters or brake pads, are being replaced as part of a preventive maintenance schedule. The rationale is that the economic cost is low enough to afford a ‘no matter what’ replacement as it’ll improve the reliability and safety of the car far beyond this cost. These maintenance schemes can be derived from historic data on a vast group of machines (in the case of cars) but can also purely result from engineering decisions made during the design phase (i.e. nuclear power plant maintenance). In both cases, cost and safety indicators are evaluated for both acting and not acting. The great advantage of preventive maintenance is that it can be planned and therefore, maintenance schedules can be optimized (some parts may last longer but are replaced because the machine is down for maintenance anyway).

The second kind of maintenance is reactive maintenance. As the name implies, this happens in reaction to an event (a failure or an indication of a problem – which doesn’t necessarily mean there actually is a problem). As one can’t plan for these events to happen, reactive maintenance is much more disruptive to the organization. Depending on the criticality of the failure, where it happens (in the case of moving assets), whether the machine is on a critical production path, etc. the failure can require an urgent intervention. When this can be served by maintenance teams not assigned to any other tasks, the disruption can be minimal (but one had to budget for the extra capacity!) but in most cases, rush interventions mean something else has to yield and the overall planned schedule gets turned upside down. This, and other direct and indirect costs means that reactive (and therefore unplanned) maintenance is 3-9 times more expansive than planned maintenance.

The third kind of maintenance is actually a subset of the first kind (preventive maintenance). It is, however, a fairly recent evolution in that techniques and technology now allow us to introduce predictive maintenance. It differs from pure preventive maintenance in that not fixed maintenance counters are put in place but rather a whole environment which allows the capture of both machine and non-machine data (i.e. weather, production schedule,…). This data is then gathered and (preferably automatically) analyzed in order to detect early warning signs of upcoming events. As such, the task of predictive maintenance is to foresee events which would have lead to reactive maintenance and transform them into planned events. This has the advantage of avoiding an unplanned event (which, as we saw, is 3-9 times more expensive) and allows the creation of a planned intervention which can become part of a preventive maintenance schedule.

Ideally, all events would eventually become planned. We all know this is pretty utopic. However, there are economic as well as qualitative arguments to set on a path towards predictive maintenance. Even if a few percent of the unplanned events an be turned into planned ones, the investment in predictive analytics (data capture, analytics software, new processes, etc.) is rapidly outweighed by the lower maintenance costs. However, other factors such as increased availability, employee morale, reputation and customer satisfaction may have even greater returns. So, when evaluating predictive maintenance, don’t just consider the many faces of maintenance but also look at the many faces of benefit to your organization.

Your forecast isn’t good enough

Here’s something newcomers to predictive analytics often feel: “this forecast isn’t good enough for me to do anything with it”.

How can I better illustrate this than by an example: imagine an asset for which failures for two parts get predicted: a motor and a monitor. For both parts, the predictive analytics system is capable of predicting 40 out of every 100 failures with high accuracy.

Here are some of the questions the eventual user of of predictive analytics software should ask herself:

  • what’s the direct cost offset of acting proactively vs reacting after things have broken?
  • what is the indirect cost of the part breaking?
  • how critical is the part?
  • what would be the cost/benefit to improve this forecast beyond 40%?

Let’s first have a purely qualitative look at the above prediction. If I can accurately – with high enough confidence and enough lead time – predict 40% of all failures, what could be the impact on my business? Well, first of all, it would allow me to plan an intervention on the equipment. This means that I could do it at a time and place (in the case of moving equipment) of my choice. Second, it would allow me to ensure I have the required parts (or even the right maintenance team) on hand. Did you know that in some cases, more than half of unplanned maintenance duration is time lost waiting for parts? And third, if need be, it would allow me to reschedule my operations around the maintenance event.

Understanding the full value of ‘knowing’ is therefore very complex and many indirect factors affect it. I recently met with a client who said it would be hard to change the maintenance processes because they were already understaffed. Application of condition-based and predictive maintenance techniques is exactly what should free up capacity through optimisation schemes, pooling effects and better planning. Too much firefighting unfortunately leads to less efforts in prevention, which leads to… more fires!

Let’s now say that in this case there is no direct cost rationale for applying the above 40% forecast. Does that mean we should not react? If the machine you’re monitoring is a lathe that is part of a production line, failure of said lathe may result in waterfall delays and a large disruption of the production schedule. So, indirect costs may still warrant a proactive intervention.

Now consider the equipment being an airplane. Does the 40% prediction of a monitor warrant an immediate intervention? The answer may differ whether the monitor is a passenger IFE (In Flight Entertainment) screen or a cockpit monitor. Even in the former case, individual airline rules (some airlines value their customers more than others) may require a direct intervention. But when something (in this case: a predictive analytics solution) tells you there’s a 40% chance one of your engines may fail, things suddenly look different and doubtlessly any airline would decide to have a look at the engine before takeoff…

The conclusion therefore is that numbers need to be looked at in context as they don’t always mean the same thing and any good predictive analytics environment would allow visualisation of data relative to their impact (financial, safety risk, etc.). Bringing together all the relevant information in an easy-to-use and easy-to-interpret environment will lead to better business decisions, saving money… or even lives.

M2M Now Blog: Smart connected products: Changing daily life

IoT Connected Products

Mario Montag was a guest blogger for M2M Now. For the direct blog posting, click HERE.

Smart connected products are changing how we make, sell, and use things. The impacts of this new dynamic include changes to the competitive landscape, product designs, and how value is created for customers. These shifts will affect every industry.

Smart connected products will enable the rise of a new IT-driven era of productivity and growth for companies, customers, and the global economy. We at Predikto agree that the swell is huge, but the wave just started. Prior IT innovations drove productivity focusing on standardisation enabling cost cutting. The next IT wave will be the tsunami of Product-as-a-Service business models allowing users to have full access to a product but pay only for the amount of product they use, says Mario Montag, CEO and founder, Predikto.

These products are disrupting traditional supplier relationships and redistributing bargaining power. The “smarter components” making up the new smart products, deliver more value relative to traditional “non-smart components”. The reality is that the physical equipment or component can now be commoditised or even replaced by software over time. Another example of how “software is going to eat the world” as stated by Mark Andreessen. With the introduction of “smarter” products, are new suppliers that were never part of the supply chain or competitive cycle before. These suppliers have access to smart product data, earning them bargaining power that did not exist in the traditional product/vendor relationship. Their leverage stems from visibility into product usage and access to end users. Now, suppliers can offer new services based on usage, equipment maintenance, and analytics.

When a product is delivered as a service, the responsibility for and associated cost of maintenance remain with the manufacturer. Rolls Royce started this more than 10 years ago with selling power by the hour instead of engine turbines. GE is making a big push in this direction as well. They no longer just sell you a locomotive; they sell you power with specific service level agreements and service mandates. Companies are offering customers the opportunity to pay for the wash cycles instead of the washing machine. The Product-as-a-Service will also impact the design of the product itself since the function can be shared across many users. A product where the reliability and performance risks shift from the customer to the manufacturer will require design modifications to enable better real-time visibility into the working condition of the equipment. The sensoritisation boom around IoT is an enabler of these product design changes.

While the end product remains relevant, the power has shifted. Consumers are no longer interested in purchasing a product as long as the services are still provided. With this transition, companies that provide Products-as-a-Service are at an advantage. They now have the power to create a “data lake”. Advanced analytics is the key to tapping into the potential value created by the massive amount of data available. The challenge we see at Predikto is that most customers only have the tools and capabilities to analyse the past. The true value is achieved at the crossroads of Diagnostic, Predictive, and Prescriptive analytics. At this intersection, manufacturers will be able to predict equipment failure, reliability, and maintenance needs simply based on external factors like the weather and other sensor collected data.

Therefore, get ready for the new wave of IT innovation that will be fueled by the growing number of companies offering Products-as-a-Service as a result of their ability to fully gain visibility and understanding of the behavior and condition of their components and equipment in real time. It’s going to change everything.

Our CEO presented at AASA conference

Mario Montag was the keynote speaker at the AASA Technology Conference in Florida this week.  The topic was “Predicting Parts Performance in the Field.”  There were 175 participants discussing how technology is impacting the automotive after market segments.

“We are all very aware that technology is changing and, to some extent, disrupting the way we do business in the independent aftermarket.” – Opening remarks from Chris Gardner, vice president of marketing and member services of AASA, for the 2015 AASA Technology Conference.

Mario also stated that there’s a large disconnect between the scientists that are putting together the current algorithms for predictive technology and the people who know the business.


Coverage on the presentation is available at: