The Uptime Blog
An article in the August issue of Airline Procurement Magazine discusses the challenges of responding to aircraft-on-ground (AOG) events. An AOG is described as any equipment-related event that prevents an aircraft from being dispatched. (This means that bad weather doesn’t count as an AOG.) The article points out that an AOG event results in lost revenue, higher maintenance costs and decreased passenger commitment. Because the impact of an AOG is so great, finding ways to minimize the impact is critical.
If you think the previous paragraph merely states the obvious, I agree. The article fails to discuss any of the means used by airlines to minimize the impact of AOGs. That’s a shame because there is a lot of software out there that can address various aspects of the AOG problem. Whether it is troubleshooting/fault isolation, parts identification, scheduling service, or inventory management, there are many pieces of technology that can help solve this puzzle.
Those of you not in the aviation industry may be wondering if this matters to you. It does. Every industry has some version of an AOG. Whether the crane stops hoisting, the excavator stops digging, the combine stops harvesting or the top drive stops turning, when production comes to a standstill companies will spend whatever it takes to get up-and-running again.
It may never be possible to eliminate AOGs. Sooner or later everything breaks, sometimes without warning. Smart companies however, find ways to guard against such risks and to reduce the cost of emergency maintenance and repairs. Maintenance software that can be fully integrated with other enterprise systems ensures that accurate information flows seamlessly, which is the key ingredient for good maintenance decisions and rapid response.
This Airline Procurement article highlighted several aspects of a serious problem—a problem that affects every industry. Now it’s time to start discussing solutions.
By Michael Israel
Having worked in the application software industry for more than 25 years, I know that certain fundamental elements must exist if both the software vendors themselves and their customers are to be successful. The first and most obvious is that the software must satisfy the customers’ business requirements. For example, you wouldn’t purchase inventory management software that was unable to keep track of your on-hand balances.
A second crucial element is technology. With the Internet permeating nearly everything we do these days, it’s not likely you would deploy a solution that didn’t take full advantage of Web technology. And if your business involves mobile workers, as is nearly always the case with field service, you’ll certainly want to be sure you select software that includes state-of-the-art synchronization and wireless connectivity features.
So functionality and technology are important considerations in selecting a software solution. An equally important factor, though, is the software vendor’s ability to help their customers implement the software, and integrate the software to other applications, such as back-office ERP systems.
Unfortunately, this crucial element isn’t always given adequate consideration during vendor evaluations. As I said, I’ve been in the software business for a long time. I’ve seen software implementations stretch far beyond what was expected or, worse, fail entirely because of poor implementation planning and execution.
For an electronic parts catalog (EPC) software deployment, this implementation planning may be even more important than it is for other types of software deployment. I say that because EPC software relies heavily on data obtained from many diverse sources. For example, parts drawings come from engineering, service information is generated by technical publications, service bulletins are created by technical support, part substitution updates are issued by engineering or manufacturing, and so on. An experienced and skilled implementation team can help the customer identify all the various sources within their company from which information can be drawn to populate the EPC database.
Moreover, an experienced implementation team can integrate EPC software to the customer’s ERP, inventory control, e-commerce, and other legacy applications, giving the users a streamlined workflow, which saves them the aggravation of having to navigate between screens or applications to accomplish a single task.
A word of caution, however; don’t think the burden for a smooth implementation rests only with the software vendor. It belongs equally to the customer. Strong customer executive sponsorship and a willingness to commit the necessary resources to the implementation project are essential for success to be achieved.
OEMs want to sell more parts to their dealer networks, and the dealers want a simple way to order parts; therefore, it’s not surprising that the shopping cart features of Enigma InService Electronic Parts Catalog are highly valued by our customers because they help dealerships order OEM parts easily. The following podcast demonstrates how shopping carts contain information such as part number and description, price, quantity, and notes/comments, as well as dealership information (such as the dealership’s unique logo and billing/shipping addresses.)
Enigma InService EPC customers usually integrate their shopping carts with a back-office e-commerce system, which facilitates parts order tracking and fulfillment. The carts can be viewed online, emailed to someone, or printed out as a PDF file. The shopping list displays those parts being ordered by the user and is associated with a specific shopping cart. The shopping list can be updated by removing parts, changing quantities, or adding additional cataloged or non-cataloged parts.
Keep in mind that the shopping cart functionality allows specific customer information and parts requisition activities to be standardized. Each shopping cart includes information specific to each customer and/or type of order. Multiple shopping carts can be defined and re-used to accelerate the creation and submission of parts orders.
Take a peek at the product podcast and let us know what you think. If you want to see more, I’d be happy to set up a thorough web demo for you.
Recently, I was drawn into a debate regarding the future of offline applications. (For my purpose, an offline application is one that continues to operate properly even when disconnected from the network.) The person I was debating took the position that offline applications will vanish within two years as Web-based and SaaS applications grow in popularity. Furthermore, they contended that current/real-time data is the only data of any real import to business. As a result, this person claimed that offline capabilities for software applications were truly unnecessary. I disagree and firmly believe that offline applications will actually flourish in the future. Using the maintenance environment as a background, I will explain why:
1. Connectivity is not pervasive. No matter how much the wireless and cable companies want us to believe that the world will be fully-connected in the not-too-distant future, a large portion of the world will remain disconnected. Whether the connection is wireless or wired, access to the network is dependent on the number of customers that will pay for it. (Anyone that has driven through a rural/remote area can tell you how unreliable the cell-phone connection can be.) Furthermore, when it comes to fixing equipment, mechanics must often work in poor conditions where network cables are unavailable and wireless is slow and/or nonexistent. (Think about weather-related outages; isn’t it funny how often networks fail at the worst time possible?) Failover is critical to customer support and so having a disconnected-mode is key to delivering services in the real world.
2. Offline processing, online storage. In all things, performance is critical and offline processing leverages the power of the workstation, providing faster results. (This is especially true when problems and solutions are unclear, requiring multiple iterations to properly identify and resolve.) Once complete, results can be uploaded/synchronized to online repositories for use by other users.
3. Backup and archiving. In any regulated industry, companies often choose to save older versions of maintenance information, which provides a snapshot to a point in time. In the case of a recall or investigation, the ability to restore or view maintenance history is invaluable.
4. Intellectual property. Offline applications allow local storage of proprietary information that must always be at hand. This is critical for collecting maintenance notes and best-practices, where user-generated content can only be understood within the context of the specific equipment configuration and service procedures that were being performed. This is also important for field engineers that service multiple clients and must guard proprietary data from exposure.
5. Connectivity costs. Unless information changes daily (hourly?) it doesn’t make sense to make online access exclusive. Given the volume of data required to service complex equipment, local/offline applications make perfect sense.
Enigma is not the only company to recognize the importance of offline applications. I see a trend of classic web applications developing frameworks that enable them to work in offline mode and combine desktop and internet functionality:
1. Google Gears
2. Adobe Air
3. Ebay (Perhaps the biggest web application ever, Ebay developed a desktop/offline application for power users.)
4. Wikipedia offers DVD and offline downloading.
The issue can be further highlighted using this simple metaphor; in a world that has reliable public transportation systems, people still use cars. A sense of security and predictability are what influence companies to retain control over maintenance data through the use of offline applications. The pendulum has shifted many times from the days of mainframe computing to desktop applications, to client (fat) and server applications, and back to the web and back again. Offline and online applications have survived the test of time, each for different reasons. It appears there will always be room for both.