Physical protection of our nation’s infrastructure happens at many levels, namely, National which includes all the United States armed forces protecting our land, sea and airspace borders. At the state level which includes state police forces, state highway patrols, and the National Guard forces. The local protection is handled by each and every local police force in addition local community civilian efforts to monitor suspicious activity around neighborhoods more commonly known as neighborhood watches.

 These amounts to hundreds of thousands of human resources that need to be analyzed managed and deployed properly to ensure the nation’s entire critical “brick and mortar” infrastructure is protected adequately and to ensure those individuals are given the proper tools to execute their assigned tasks. The question becomes how do we effectively inventory all of the nation’s human and physical resources in order to facilitate real-time assessments of our ability to protect our critical infrastructure?

 That question presents several seemingly insurmountable problems… Potentially tens of thousands of local level sources of data, thousands of sources for state level data, thousands of sources of federal data in addition to thousands of data sources contained within the firewalls and control of private and publicly owned companies as is the case with major power distribution and communication corporations. To make matters worse there could be hundreds of different software vendors that support the collection, storage, maintenance, and reporting of this information. Each software package has a unique and often proprietary data model and most likely a unique and proprietary meta data schema used to tag the meaning of each database field and values within those fields. Without consistent and easily discernable database schema from each data source, integrating the mass data becomes an impossible task to do in a way that the resulting information can be trusted to make decisions in what amounts to life or death situations.

 One potential solution to this problem is a combination approach which would include a National Master Data Management initiative with the ultimate goal of achieving a level of data quality sufficient enough to accurately derive infrastructure intelligence information to be used to assess the vulnerability any given infrastructure asset has to attack and the potential damage and casualty fallout if an attack were to occur at a location such as any bridges that carry large amount of cargo across the Mississippi. Not just any data will do when allocating resources to secure and protect such important national resources; the data needs to be quality data, data which consists of profiled and standardized vocabulary, the syntax or format of the data, the provenance or source of the data as well as the accuracy and completeness of data. Data that does not meet minimum requirements for the metrics I listed previous can not be used to make decisions that are supported by accurate data.

 My proposal of a National Master Data Management Program would in its most basic description include the creation of a national mashup of these thousands of data sources into one Infrastructure Security Data Warehouse that would be used to govern, analyze and report the readiness of the nation’s infrastructure if an attack were to occur.       

 A mashup is a relatively new term used to describe a database application that pulls information from tens to thousands of data sources and integrates the data together so it can be analyzed over and over again. At the same time would not require the replacement of the thousands of legacy systems the local, state, federal, and private entities use to run their day to day operations.

 I have oversimplified the problem and solution in this explanation, the actual solution is very technical and requires professionals who have managed data integration, data cleansing, data governance and master data management programs in the past. An initiative like we are proposing is not a short term project with a defined beginning and end date, in reality the project began more than 30 years ago with the collection of electronic data. A master data management program for something as critical as the United States infrastructure is not simply a program; it is a complete change in the thinking and the way we interact with the data we spend so much time, money and resources archiving and cataloging. It is a cultural change.

 More technically speaking the idea is to create a classified open technical dictionary which will contain all the terms and definitions needed to describe, at their most atomic level, every single data field we require to generate the information needed to assess and prioritize potential infrastructure targets. We will then tag or associate one of the classified numbers and terms to every single piece of asset data (Master Data) determined necessary to implement the infrastructure protection strategy. We will use a combination of publicly available meta data and newly created meta data to tag all the data elements. This allows us to store and report on them quickly and accurately from a central location with a centralized team, resulting in a true Infrastructure Intelligence Master Data Program. Once all the target data is in a standard format we can further national security goals of increasing the level of quality related to information and reporting, increase the level of interaction between local state and federal authorities and provide threat advisories to citizens and the law enforcement community. As well as providing data that can be used in a variety of training exercises and computer simulations of potential attacks.

 Core to the proposed data quality/master data management program are the business processes used to carry out the data cleansing and enrichment processes. The methods used NEED to be vetted and thoroughly tested with large datasets and algorithms comparable to the complexity of the algorithms that will need to be developed to predict things such as; How many people will be effected if a particular power substation is physically or cyber attacked?, Which railroad infrastructure is key to keeping the flow of military supplies to ports for distribution to our forces worldwide?, Once a threat is identified how long will it take to mobilize enough manpower to properly defend any given location?, Which power generation facilities are large enough that if damaged would results in blackout for 5% or more of the population?, Which open air water sources, if poisoned will cause the most death?. The processes and methods used to execute the project in its initial phase and on an ongoing basis are just as if not MORE important than the quality of the initial data sets, they are mutually independent on each other.

 The implementation of an ongoing and permanent national Infrastructure Master Data Management initiative would be of great benefit and could be essential to the long term growth and protection of the United States of America.

Every day I make decisions. Some turn out to be the right ones. Some turn out to be horribly wrong. Since I accepted the role of product manager rather than simply a project team member, I have put a great deal of thought around decision making. I ask myself questions like: “What information do I need to make a decision the right one?,” “At what point do I have enough information to make the decision?,” “Does the outcome of each decision I make effect the remainder of the product launch in a positive way?” I still can not answer all the questions I have about decision making. However, I have used the following principles to aid in making the right decision most of the time:

1.) Make lots and lots of small Decisions. When you send your developers off on a mission to complete a large section of code or forge an entire revision to an app in one shot, there are inevitably a lot of decisions that have to be made along the way. If your development team has to make these decisions on the fly, against an imaginary timeline, there is a large chance the decisions will be made without all pertinent information. It’s more likely each small Decision will be the right one if you use all the information available from the complete team at each point a decision is required.
2.) Keep the communication channels open between developer and subject matter experts. I recommend daily touch points of less than 15 minutes. Meetings are expensive, time consuming and often attendees are never prepared. I prefer discussions to take place at the programmer’s workstation while he or she is working on changes. This allows demonstrations of current and expected behavior to be shown immediately. Real information and real code turns into a visual aid. It is important all team members understand the purpose is not to meet the schedule. The real purpose is to launch an application people love to use. I might go as far as saying it should be expected that as you move from design to development, you’ll need to make lots of little changes along the way. I question any development cycle where there is little difference between the original designs and the product at launch.
3.) Test, Test, Test. After each Decision there should be some time spent to test it. Testing does not have to be a project in itself. Testing should be performed by both developer and the team member who is in the best position to interpret what will and will not benefit the end user. Testing at each available opportunity is essential to minimizing the amount of change required after a bad decision is made. For example, if a change is made and not tested, each change implemented from that point forward could require revisiting if it’s found the original change was in error.

These principles also contribute to a pleasure filled work environment by allowing each team member to work on what they love. Development does not have to sit in endless conceptual meetings, nor does the product management team need to wait months or weeks to debut new features. The three principles I illustrated above can and should be applied to any development scenario. Using these principles to govern product testing and design reduces our development cost and gets our product to users faster. And in the end, that’s what it’s all about.

The same logic of presenting every imaginable, option, configuration, button, screen, step, radio button, piece of information has been applied to many software packages. You would think in a large organization, simplicity would be king…not so…I am currently consulting with a large multi-national organization to help in the deploymentof a centralized system to house all product information for their MRO or Maintenance, Repair and Operations. Which, in practical terms, means that they are centralizing their databases of information required to order, maintain, and use any item that can potentially be purchased but does not go into their final product.

Not a small task by any measuring stick. Master Data Management, data cleansing, data normalization, intra-organization de-duplication are on the radar of most if not all large businesses. The most important part of the process is to choose application(s) that are the best fit for your organization, not the one that is made or owned by the largest company, and not the one who has the most clever marketing, not the one that appears in the latest report by the best marketed research firm (think about the ratings agencies who rated toxic subrime mortgage backed securities AA or AAA)

The software that was chosen xxxxxx (contractually obligated not to say the name) has one main screen for entering most of the data related to any given item, this screen contains no less than 50 possible fields in tabular form. There are also 3 additional screen each with less than 50 fields for data entry, these subsequent screens are used to associate ansillary information such as pictures to an item. The screens that DATAForge uses – one screen with 25 or less (depending on the type of data). The remainder of the information is gathered organically and seamlessly based on the way the application is used and who is using it.

When we design a solution the question on each team members mind is “How can I make this easier and faster to do for the end user?”

When evaluating an application force the vendor to show you how it will be used (not tell you), make them show you their solution is faster and more efficient. Lots of options, inputs, and fields are not always the users friend.

Buyer/supplier information synergy to me means that at any given time, if a piece of data is needed to complete a product description or a piece of data is needed to place a product or service order that is not available in your ERP applications, your suppliers are willing and able to provide the piece of data automatically without human intervention.

That probably sounds ridiculous.

This situation probably sounds more familiar:

1.) New equipment is installed
2.) The recommended spares list is loaded directly into ERP
3.) The new equipment malfunctions, goes down
4.) Production stops
5.) The maintenance department attempts to replace failed component only to find there is no inventory
6.) Maintenance frantically calling machine builder/suppliers/plant engineering to identify the failed component

This may be an over simplification or might not be something your organization can relate to, but, there are several types of technology and business process that enable prevention of this scenario and other problems that plague the large manufacturers supply chain.
—a common unified schema or dictionary used by all commercial organizations to label product information (eOTD)
—a common method of transmitting this information directly into ERP prior to the need arising to replace a component (xml)
—develop a supporting business process to ensure the needed information is requested (people)

As manufacturers/suppliers/BPO providers we all need to work together to move to a common method of requesting, transmitting and receiving the information we need to keep our operations running.

Yes. 

I was first going to define what Software as a Service actually is. When I tried to find a clear concise definition I had trouble finding one covering all the possible deployment, payment, and support models.

This is what I came up with:

Software as a Service – A software application that is available exclusively for use through a web browser,  paid for using a pre-determined payment schedule based on predefined usage metrics negotiated with the SaaS provider, and supported by an entity that is not the end user or end business unit within an organization (regardless of where data is physically stored).

This is the Wikipedia entry for Software as a service.

This is what Oracle has determined SaaS to be.

Here is what PC Magazine has determined SaaS to be.

I encourage you to form your own definition and let me know what you come up with.
The major issues that have been communicated to me as reasons why manufacturing IT executives are hesitant or completely unwilling to place their priceless data inside an application almost completely under the control of a third party are as follows:

1. Security is by far the greatest concern, and it should be high on the list, it feels like almost monthly we hear about another data base breach at a major credit card processing firm or student medical information stolen from a university data center (Hackers steal UC Berkeley health  records). Unless you as an IT executive are confident your organization has security measures that are far superior to those commercially available, security should be knocked further down the list of concerns. We have all been using SaaS for many years to facilitate the business of moving actual money for years. Can you name a bank or Fortune 1000 manufacturer that does not use some sort of electronic tool to transfer money or process payments? The issue of security as related to SaaS should be thought of on a case by case scenario addressed individually with each provider you are considering sourcing your software from. This should be done before any contract is awarded prior to any data being placed on infrastructure outside your control. 
2. Availability aka uptime is also a major concern. If the data is not accessible all the time how can the business run? The answer to that is determined by the criticality of the data. You would be hard pressed to find an internally hosted application that has not experienced some sort of downtime, especially when you consider the volume of patching Microsoft performs. Aside from natural disasters or area wide network outages, downtime can be addressed through proper planning and effective communication between the service provider and the customer base. 
3. Cost cutting on hardware . . .  Depending on the type of master data being stored and the data model being used to store it there are many options for hardware configuration. Options like dedicated vs. shared server hosting models can be a huge factor in determining the cost to maintain a hosted SaaS solution. If the data is financial in type, then most certainly dedicated hardware should be used. On the other side of the servers if you are storing data like spare part information, most likely available without so much as configuring a password, why not utilize the cloud. When a hosted SaaS solution is implemented hardware, support, hosting is all moved into a usually reasonably low monthly payment.

Yes. If properly planned and properly implemented software as a service is a realistic solution to alleviate many issues with internally hosted and maintained applications.

The problem? . . .  you are probably asking. The problem is that the reporting and analyzing process to attain the intelligence information all happens after the fact. The spare part has already failed, the maintenance person responsible has already been to spare storage and realized that the critical spare is not stocked, the purchasing rep has already issued a PO to a local supplier for a much higher dollar amount than warranted by the contract with the actual manufacturer and the business intelligence as you call it, happens only after all of this has occurred. This is NOT business intelligence; it is simply and only historical information.

In better fiscal times, these issues weren’t a problem any part of the organization wanted to tackle. We all had large staffs of highly trained and experienced MRO professionals, who knew their manufacturing facilities like their own home. Cars, boats, planes, bicycles, mp3 players and consumer goods of all types were all flying off the shelf at records numbers. Margins were high, and there may not have been enough pressure (bottom up/ or top down) to make a large capital investment in an enterprise class business (manufacturing) intelligence platform. Things have all changed; resources across the board have been slashed faster and wider than ever in the last 2 decades. Is your organization prepared for the coming era?

This may seem like random rambling . . . I have a point. 

We all have MRO information, master data, and historical statistics. All of which is only information, raw data until it is put to use in the right manner. The key to the usage of this information is foresight. The information needs to be gathered, analyzed, and most importantly disseminated in real time to the people who need it to make REAL TIME business decisions.

Over the next several years I see more and more pressure put on IT and business process leaders to put in place solutions that can aid in making real time decisions before the problems happen.

Are your manufacturing/business decisions made after the headaches or before?

CR