1. One of the most common situations we encounter is that of Invalid equipment, work orders, PM schedules, inventories, material requisitions, purchase orders, invoices, etc., which have been converted from the legacy system into the current production system and in the process invalidated many of the online queries. As was discussed in a previous Q&A Corner issue, this can also cause a great deal of confusion as to the status of equipment or orders. In some cases, the invalid data was not recognized in the legacy system, while in other cases, the invalid data was recognized and the decision was made to convert the data to the new system anyway without a post-conversion cleanup plan.

To rectify this situation, I’d recommend forming a team consisting of data experts from the IT organization and the business unit, along with an outside consultant who has years of experience doing this type of work. Analyze the tables to determine the disposition of the data:

• Delete - no value, invalid, duplicate, etc.
• Archive - historical significance but real-time access not required.
• Keep - supports the “to be” business process. Note: data that is retained may require to be cleaned-up to a defined standard that supports     reporting and analysis.

Because the data tables are complex and tightly integrated (normalized), test your processes and programs in a test environment prior to working in the production region.

2. Another situation that we see frequently involves a scenario where the conversion data wasn’t validated for the new process. The result here is that more often than not the converted data is incomplete, or improper data is converted. For instance, it may be possible to load preventive maintenance criteria which on the surface look OK for some of the records. If after the load, only a few dozen records are tested, it is possible that the bulk of errors will be missed.

Our recommendation in this situation calls for developing a properly structured validation plan during conversion from the legacy system to the new system, following guidelines as provided in MIL STD 105E. This process ensures data accuracy provided the process is followed. With products like the Indus’ PassPortTM system, it is very easy to miss some vital data links or to establish invalid data links during validation for some of the data unless a rigid validation plan is in place.

3. In more than one environment when installing an EAP application, on site programmers have been given full access to data and are responsible for writing maintenance queries on the new system without knowledge of the data interconnections or links.

Our advice is that while most organizations today prefer to use in house programmers for the majority of their resource needs, skill set transfer and technical training are important components of a successful implementation. The in house programming staff may be very skilled, but it is vital that when writing maintenance queries against the new system that programmers be familiar with “all” the possible connections. It is almost impossible to write an update query against one table without a “where” clause on another table, and in some cases, more that one table.

• Rules for structuring information by using your own vocabulary
  
  
• A language for formally declaring the vocabulary your company uses

Hence the need for a strong stable backbone when interfacing business process objects such as work orders, material requests, purchase orders, time sheets and accounting transactions.

by Dan Duffy of BlueSky Integration, an Alliance Partner of iStrat Support Services

4.We'll be starting a PassPort™ upgrade project in the first quarter of 2004. We're currently on version 6, and we're planning on going to the latest (Version 10) version available. We're pretty customized in our current system. What advice do you have for us? When should we start the planning sessions?

Let's start by listing some of the determining factors. First, we'll assume here that the business case has been approved. The next thing you want to look at is how much process and technology change will be involved - basically, what is your scope? For this response, we'll assume that you are upgrading one site with a few hundred end users. We'll also assume that your IT department is internal and equally engaged in the project.

With that backdrop, let me just offer you the following points, and then I'll come back at the end and tie these together:

• During the lifecycle of the upgrade, you'll need several additional environments created by your IT organization. Your end users will still be using the existing systems, so you'll need to continue dedicating the same level of resources on the hardware side of things, plus your additional project needs. You may be able to combine one or more of your existing environments, but it's a given that the overall hardware resource needs are going to increase. You'll need to line up additional table space then, which may in turn require more DASD and other physical resources. Because this hardware may have a significant procurement lead time, you'll want to identify any barriers or constraints as early as possible.
  
  
• On the data side of things, understand that going from 6x to a more current release is essentially a new implementation. The data conversion may offer some streamlining opportunities, but the functional and architectural differences alone between these two versions are enormous. Since your current software is customized, hopefully the changes have been documented in the code and in the process documentation from previous implementations. If not, reconstructing the customizations can cause significant delays in the project.
  
  
• Another area to consider is the amount of process change that will be involved. If you're still using the version of software that was implemented initially, my guess would be that there are many functions available in the software that you're not using (check the product documentation). Since you'll be upgrading to the latest Baseline version, you need to understand what functions will remain, which ones will be added, and which ones will no longer be available.
  
  
• The final consideration in early planning has to do with your education objectives and scope. Changes in functionality normally will be directly proportional to process change, which in turn correlates to education scope. Assuming your customizations aren't factored into the code base you'll be implementing, the education and training scope can be pretty significant. Which brings us back to Senior Management - getting to baseline is a noble objective, but it can be an enormous challenge too, depending on the gap between your processes today and what baseline will support.

5. Who needs iStrat - why does the implementation business need yet another choice?

Interesting, and a fair question - from the outset, we've been driven to build a company that at the center has the culture of customer focus and which is staffed with experienced professionals. Senior management at iStrat know that successful teams are populated by people that demand to be challenged in their work, and who possess a 'whatever it takes' work ethic. iStrat's Management is absolutely evangelical in their desire to correct what they see as a lack of integration between systems and process today. We believe that we're significantly different than our competitors today in this sense, and that given an opportunity, we can deliver ROI that far outweighs the cost of our services.

return to top

6. What makes iStrat so qualified to manage PassPort™ projects?

There are a number of firms you can turn to when you're looking for PassPort™ support - clearly, the same is true of any EAM, ERP or other enterprise-wide support. For the most part, they all have some good resources, and with a couple of exceptions, the rates will be pretty comparable. What we think differentiates us are three things:

• First, as a result of our standardized implementation methods and because of the templates we use, our implementation and upgrade lifecycles tend to be 25% - 50% shorter than most other companies you might use. Ridiculous claim? Our most recent implementation involved bringing two additional facilities on line, and we met each of the project objectives in just under four months, from Project Planning to Production Cut Over.
  
  
• The second thing that we think distinguishes iStrat from the competition is the experience our resources have. Because iStrat Senior Management have been engaged in the technology and utility industry's for nearly 30 years, they have developed and maintained relationships with premier PassPort™ and industry consultants. Many of these people have since chosen to join or partner with iStrat, and the numbers of resources available that have been working with PassPort™ for eight to ten years is greater than any of our competitors. We don't put 'green beans' on your site, expecting our customers to train them. Likewise, we make certain that we have the right skill sets for what our customers require.
  
  
• The third thing that differentiates iStrat is that we don't try to turn a three month project into a 30 month project, and we don't tell customers they need 3 resources when 1 can do the work. We strive to make customers as successful and self-sufficient as possible, and leave the customer site with their implementation goals met, and some dollars left in their budget.

return to top

7. What releases of PassPort™ does iStrat support?

We support all releases of PassPort™, including those that are highly customized.

return to top

8. How can I get additional information about the services that iStrat provides?

We've made a number of brochures available on our website. Those available on the website include Corporate Overview, iStrat Products and Services, iStrat Workshops, PassPort™ Services, and EMPAC™ Services. Additionally, you can contact us via e-mail at info@iStratsupport.com, or call us at 619.282.1474.

return to top