02 January 2005

XML Feed Integration: Emergency Response Support

Summary

This is a solution to the Tsunami coordination effort. XML feeds could be integrated to improve coordination monitoring.

Discussion

Dissimilar agencies have quickly aligned their efforts to provide relief support. One problem has been the disconnect between when goods have arrived, and when the subsequent delivery channels have been ready.

This is to say the international community has quickly delivered the food to the airport, but there was no follow-on effort to transfer the goods to their final destination point.

One solution is to ensure that goods are shipped only when the logistics-support is in place. In other words, rather than ship boxes of aid first, a more prudent strategy might have been to focus on ensuring that there were fuel dumps and trucking along the routes.

Clearly, the international community has adjusted. The goods are in the airport, and helicopters have provided the supporting airlift. However, the process has been slow--US Helicopters only able to move approximately 1,000 – 1,800 pounds per trip.

This note discusses whether there could be superior results had other support mechanisms been in place. Name, if information about total tonnage were aggregated, could the planner have known to slow down end-item delivery and focus on logistics support.

Also, this note outlines several strategies by which XML-feeds might be integrated to provide support in a disaster support effort.

Integrating XML feeds into a single area map

US military planners during the First Gulf War used a system called JPATS to visually monitor the traffic along the road from the Gulf into Baghdad. Also, other GPS systems in Gulf War II allowed US planners to identify the exact location of individual warfighters. The results allowed war planners to align forces to swiftly engage targets.

This note proposes applying a similar principle to relief efforts. In all probability, logistics planners have a central tracking system allowing them to see where the goods are.

What it does not appear to have is a system to integrated different relief agencies into a central visual map in a streamlined fashion. This is to say that when an international effort starts in response to an international crisis, the world cannot simply hope that a single organizational body or government can effectively organize all detailed efforts.

Rather, this not proposes a more automated approach whereby the individual participants, relief agencies, and governments provide through XML their data in re: Relief supplies, shipment times, total tonnage, and types of goods.

At the same time, this note also proposes that media outlets also provide XML-feeds into this central data-collection point, and the XML-feeds be stripped of their valuable information related to names, locations, types of needs, and other damage reports.

In short what is needed is a platform that will aggregate the supply and demand data and provide a single picture which all players can see.

It remains to be seen whether this single system already exists. It may be a matter of simply using a single aggregator. What would be new is a means by which all players would have access to this information and also visually see the disconnects between what is reported as a requirement and what is actually in the logistics pipeline.


XML feed integration during relief efforts


  • Single map of the relief area
  • Requirements: Relief area requirements
  • Supplies: Relief support material
  • Deltas: Disconnects between the requirements and supplies
  • Bottlenecks in the pipeline

  • This note also proposes that there be an ordering function of the XML feeds. This is to say that during a relief effort there are certain orderly functions. We first provide emergency response before we begin introducing elements required for long-term development. This is to say that we provide emergency food supplies, before we delivering the wood and cement needed to rebuild recreation areas.

    This note also proposes that the XML feed integration effort also have a system to visually depict the various logistics routes such as air, rail, road, and sea. One data set supporting this effort could be the type of information from LandScan.

    During an emergency situation one approach would be to monitor the media information, text messages sent via XML, and other XMLfeed integration, and then strip out the key data such as location, mode of travel, tons, number of victims, and travel times along the various routes.

    The central image would have universally-recognized symbols which end-users could quickly understand to mean: Truck, road, canal, highway, bridge, airport, railroad, mountain, and port.

    This data would then, in turn, be aggregated into composite picture or animation of the area of interest to include distance-time charts, requirements, fuel-time, and deltas between requirements and supplies.

    Reliability

    Also, another analogy for this system would be to have a central rating system on the reliability of the various players and the sustainability of a given logistics effort. This is to say that Charity Navigator provides a snapshot relief agencies, and this type of approach would be useful information for the central XML-integration image.

    The various factors or items of interest would analyze the various elements, players, and travel modes-routes along various parameters useful for logistics simulation, to include:

    - Factors
    - Indicators
    - Relationships
    - Competencies
    - Responsiveness
    - Oversight and reporting

    One common problem with simulating a disaster relief effort is getting reliable information on the times related to travel, numbers, and standard deviations. This aggregated XML-platform would hope to overcome this challenge by stripping out the key data needed for simulations.

    In turn, these simulation results could be applied to program management tools which would properly time the arrival times and sequencing of key relief goods. Simplistically, this means making sure:

  • We get emergency foods before long-term cement;
  • We also have in place the needed travel support before ports become overfilled with perishable food; and
  • There are secure areas for relief supplies, with adequate fuel and trucks in place to transship the goods before staging areas become congested.

    To review, what we propose is simply having an integrated tool that will allow relief agencies and affected personnel a single image of the area of interest. XML feeds could be stripped of valuable information, and this injected into both simulation efforts and program management tools to time the information.

    XML feeds to individual gifting

    The next step is to take the individual case needs and apply the XML feed concept. This is to say that we could use the XML feeds to identify individual requirements and allow individual donors to sponsor individual relief needs.

    For example, a given fisherman on the coast of Sri Lanka may simply have the requirement for a single boat. Rather than have the entire generous world duplicate the requirement and provide multiple gifts for a single need; what could be done is to generalize this information so that individual donors could see the specific end-item they are funding.

    Think of the Amazon.com gift program. The public can set up an account and allow donor to provide through Papal direct contributions to a particular gift. The donors, as if they are using a wedding registry, would like to provide funds for a particular need. They don’t want to buy 12 bipods, when the end-user only wants one.

    So, applying this concept to relief efforts, what could be done in this “single aggregated picture” is to allow the donors to identify specific requirements. Think of E-bay. We have a system of matching both buyer and seller; this is analogous to the market trading programs used in the NYSE and NASDAQ: A buyer and seller are automatically matched.

    This XML feed integration tool would work on the same principle. But also integrate the LandScan information. Specifically, with respect to Sri Lanka, we know we have a single news report of a fisherman who lost his fishing boat. But what we also know from the LandScan data is the aggregate fishing requirements along the coast, the likely number of fisherman, and an estimate of the number of affected personnel.

    Using the magic of statistics and simulation, the XML feed integration tool could pinpoint with precision the likely number of fishing boats that the area requires. In turn, individual donor funds could be supplied to fulfill this requirement. Thus, there would be more efficient matching of relief donor funds to the end-user requirement.

    In turn, the next step is then to ask: How do we get the end-material to the user; what do they need in the meantime; and what other goods will they require to support this effort. This is another way of saying that XML feed integration doesn’t simply end once we throw dollars at the problem.

    Rather, the next step is then to aggregate the information into the composite picture, and identify the specific source of relief supplies. In the case of the Sri Lankan fisherman, the next step would be to identify the physical location of the wood needed to build an intermediate boat; and then identify the route and needed support entities to physically transfer the material to the area of interest.

    The next step would be to identify those personnel needed to transfer the raw material into the end product. When all these steps are completed, we have a single shipment: Funds allocated against a specific requirement; the end-user knows the funds and material are on the way; and the intermediate transshipment points are scheduled based on priority.

    At this juncture, the system has a completed requirement. This is to say that the system now has a valid purchase. Clearly, the reality sets in when the goods have to physically match with the end users.

    This is where the ongoing monitoring elements fit into the XML picture. As the goods are shipped, records are kept of transshipment times, distances traveled, and time goods are sitting waiting. This is key data that can be aggregated so that central planners can identify bottle necks.

    Also, if the end user can see that their need is completed, but they are just waiting final delivery, there could be better planning. The end-user would know that they have X-days before their final requirement will arrive; in the meantime, they can set-up alternatives, and know with confidence that “they don’t have to worry about that, but can focus their energies on alternatives or more immediate needs.”

    In the case of the Sri Lankan fisherman if the “end-user requirement” was to have a fully motorized fishing boat, the aggregated system may say, “We can give you that in X-days; but a more immediate solution might be to use this less complicated workaround such as we provide you the lumber, and also give you training on how to make a wooden boat until the far better motorized boat is available.”

    In short, although the end-requirement may not be available, the end-user could then get alternatives to satisfy short term requirements. This is to say that although the final boat may not arrive for many weeks or months, the intermediate term, there can be a new job order for wood, training, and other materials; in turn, the end-user would then know, “I’ve goat a boat on the way, but in the meantime I could set up a training program with my other fishermen-friends, and we could learn how to make boats and then be on our way.”

    Another alternative would be to show that the real-end-requirement will not be filled for X-months; so personnel in the affected areas need to develop alternative methods to solve their problem. This means that on an individual basis the affected personnel would know that there is a plan in place to address their long-term specific needs, but in the mean time they have some alternatives and options to still get fish: Make a boat, get training on how to make a less sturdy boat, generate some income through less sophisticated efforts, and work with others in the immediate area to create a production work center to expedite the production and manufacture of a large number of individual wooden fishing boats.

    This is not to say that making fishing boat is easy. Rather, this is to simply suggest that rather than wait for the “ultimate product to arrive,” there could be training programs in place to get fishermen to work on small sections of a production line that will get them to an intermediate point. If they can be organized, this will keep their mind focused and more hopeful that there are efforts in place to get things back to some semblance of normality.

    The above scenario may seem extraordinary. But think of the idea of satellites providing real time updates of individual units on the battlefield. Once, it was just science fiction. Now, it is the way things are done.

    The above approach would hope to eliminate bottlenecks, and better dovetail relief supplies with needed logistics support efforts. When funding comes it, it would make sure funding goes to the specific support elements, in the proper sequence, and assist planners in knowing which items need to be prioritized, and which need to be delayed. In some cases, there may be some counter-intuitive shipping priorities: Yes, we need to get emergency supplies, but because we have known bottlenecks, and bridges are out, we may need to ship first large equipment like front end loaders so that bridges could be created to transship critical relief supplies.

    Also, the model would identify those cases were assumed travel routes were out, and alternatives were required, thereby affecting the shipment packaging. This is to say that if the original logistics line was assumed to be a road, but the bridges are out, the alternative may be to get naval vessels to arrive at a relatively small cliff, and have sea-bee type military personnel arrive to physically carve out a new port of entry, and then build a road directly into the affected area.

    Goods that might have survived a monsoon sitting in the airport waiting area might have to be repackaged in a different way if they were to be moved by sea and then transshipped by pack-mule up a steep mud ravine. Goods that might have been packaged as bulk-items on the assumption that they could be moved by forklift, might be broken down at the original-shipment-start-point into individual relief boxes so that they could be easily moved on the backs of pack mules.

    Again, this is not to say that navy units have a superior planning method. Rather, it is to suggest that once the aggregated information can be physically seen, planners might have a better notion of what needs to be shipped, delayed, and how goods need to be packaged.

    We would make sure that the necessary protective gear and packaging required for the worst-level travel mode would be incorporated. This method would also ensure that fuel and trucks and protective gear would arrive first so that subsequent supply shipments could be moved out of the way, rather than create bottlenecks.

    The approach would also ensure there is a logical flow of tasks. Predatory task, start tasks, and closeout procedures would be timed, and planned. The approach would also display alerts when input items were not adequately flowed; or when inputs were out of order.

    A signal would be sent that there needs to be attention on earlier tasks or requirements; and the information would also signal a forecast rate of arrival which would flow into job planning packages to make predictions on the work flow, and identify bottlenecks in the requirements to support the end effort.

    Program Management of XML feed inputs

    In the short term we would focus on what’s needed, doable, and easier

    As time progresses we would work toward the final requirement.

    For example, if the end-user needs a truck to go into the trucking business, we might, in the short terms ensure that there are the requisite support elements to prepare for this final requirement.

    Before we can drive, we need to have fuel; and before we can go down the road, we need t make sure there are places to buy fuel, and also places to physically store the trucks. This simply means making sure that the personnel, if they want to eventually drive trucks, need to have the brooms, shovels, and other hand tools to physically prepare their location for the intermediate equipment that will construct staging areas.

    This system would ensure the fishermen have the tools needed to support the intermediate solutions. We may hope to provide a nice boat; but in the short term, the fisherman may simply need some wood, solutions on how to make rope, and some brooms and shovels to clean out the coast line where they will work. Ultimately, the major replacement item will arrive, but not without many intermediate steps.

    The system would also use a DHL-UPS-FedEx type approach of package tracking. Money and material would be transferred to the end user. XML feeds could be created to create the bills of ladings, and centrally manage the status messages of materials. The bill of lading would give a level of fidelity useful for trend analysis, auditing, and ultimately ensuring the need was adequately met.

    Program management

    The system would identify the individual with the specific requirement, and all intermediate steps to get the package delivered and identify the required delivery purchases of fuel and the needed repairs along the roads and bridges to solve the specific issue; and identify alternative workarounds and necessary supporting elements to physically move the item from the point of purchase to the client.

    The integration tool would flow the work tasks needed to support final delivery and identify:

  • Work order and steps needed to complete the requirement;

  • Physical material and products that have to move and the method of travel;

  • Bottle-necks and disconnects in the requirements and supplies; and

  • Needed changes, and workarounds in the goods delivery pipeline.

    Data would include:

    - Distance
    - Start, stop location
    - Travel mod
    - Fuel, labor, and overhead costs

    Also, XML feeds would be stripped of vital plans and concepts. Novel questions would be identified and flowed into the planning and simulations. For example, questions related to long-term requirements, although a more distant concern, still need to be identified as a valid requirement which ultimately need to be planned for, schedule.

  • Can the plant crops
  • How much salt is in the ground that was otherwise fertile
  • What alternative work efforts can they productively be engaged as productive employment to account for the immediate loss of infrastructure needed to complete this tasks
  • Are we rushing with front end-loaders, when all they really need are brooms and shoves in this isolated area?

    Also, when planning for the long-term efforts, questions may arise such as:

  • If the roads from the northern port in Sri Lanka were originally designed for X-type of travel tonnage, what impact would the additional travel on the existing roads have on the failure of the bridges along the relief effort?

  • What alternative and back-up travel routes need to be planned so that when primary roads fall apart, the back-up roads are there so the primary roads can be repaired and brought back up to the standard to physically handle the increased tonnage and cycles along the bridges?

    This is to say that once the relief efforts starts, the planners will have long-term requirements that may fall outside the core focus of the day to day planners. In other words, its all well and good to have XML feeds providing data on the supplies; what’s also needed is XML-related data that construction engineers can use to analyze what back-up travel routes are needed so that primary travel routes can be repaired without having any impact on the shipments.

    This is another way of saying that the existing crisis can be analyzed in terms of “we know we’re going to have to travel along this route, but this was not planned, so let’s simulate X-number of convoys and estimate when the bridges might collapse; and then let’s plan with adequate lead time so that there are adequately alternative routes in place so that we can ensure the supplies continue to flow from the northern part of Sri Lanka into the southern provinces affected.


    Review


    Current roads not washed out by the Tsunami are not likely designed for this volume of traffic. Need alternative roads prepared with adequately lead-time to ensure there is a seamless transition from the primary road to the back-up travel models. This will allow primary roads to be shut down for repairs, and traffic diverted to the alternative routes, and still ensures the alternative routes can sustain the traffic despite the monsoons and high number of convoys.


    XML feeds for innovation

    Also, during the crisis relief efforts, there needs to be a method to centrally disseminate new ideas and best practices. Again, this is not to say this is not being done. Rather, the aim is to ensure that the central XML aggregator is also used to identify novel solutions to unusual situations.

  • Water kits

    For example, some may realize that desalinization is the major constraint. They may see that although the Indian Army can adequately airlift water, a more viable solution might be to provide kits via air that victims could create that would desalinate the sea water.

  • Osmosis Trucks

    Also, an engineer may come up with the idea of integrating reverse osmosis filtering into a confined space; all that is needed is a sponsor to fund the kit-upgrade to the vehicles. The kit might have a small storage space for sea water; membranes for reverse osmosis; a storage tanks for freshwater; and a storage area for bottles of fresh water.

    Combined desalinization and oil refining

    Another example is creating a single ship which can both drill oil, refine, and conduct desalinization efforts in a safe and healthy way. This ship would carry the equipment, pipes, storage containers and trucks needed to move the end-liquid to the final client.

    Oil tankers could also be modified. Unrefined petroleum in one section, a second section containing a sea-based refining capability, and a third area to store processed fuel. This fuel could then be offloaded to pipes or small boats which could take the fuel inland to the affected areas.

    Edible paper

    Also, there might be efforts to print on edible-paper relief messages, directions, and instructions. Just as you have ink embedded in your checkbook to create a carbon copy, so too could paper be manufactured that has in it embedded micro-capsules of water that would aid digestion. Rather than having to lift heavy bags of water, perhaps foods could be created with necessary water already encapsulated at the cell-level.

    The goal of this XML platform would be to quickly disseminate these new insights so that funding could be allocated to the equipment and produce the end product for the end client.

    Summary

    This note outlined a general concept of integrating disaster information into a central location using XML feeds. The concept relies on aggregating existing information, stripping out valuable data, and then injecting this information into simulators and program management tools.

    This approach would facilitate central planning, minimize duplication, and ensure that relief efforts were coordinated and that products were timed to ensure logical arrival.

    The centralized system would support effective packaging, product sequencing, risk analysis, simulation, program management, eliminating bottlenecks, and identify workarounds. Also, end-clients could be matched with individual donors, and funds could be allocated to similar requirements based on anecdotes.

    Finally, the system would ensure that trends were identified, new ideas quickly disseminated, and necessary long-term alternatives in place to support the overall relief effort.

    We saw that integrated data can be combined during times of battle. We could very well see the same picture during relief efforts.


  • Summary

    This is a solution to the Tsunami coordination effort. XML feeds could be integrated to improve coordination monitoring.

    Discussion

    Dissimilar agencies have quickly aligned their efforts to provide relief support. One problem has been the disconnect between when goods have arrived, and when the subsequent delivery channels have been ready.

    This is to say the international community has quickly delivered the food to the airport, but there was no follow-on effort to transfer the goods to their final destination point.

    One solution is to ensure that goods are shipped only when the logistics-support is in place. In other words, rather than ship boxes of aid first, a more prudent strategy might have been to focus on ensuring that there were fuel dumps and trucking along the routes.

    Clearly, the international community has adjusted. The goods are in the airport, and helicopters have provided the supporting airlift. However, the process has been slow--US Helicopters only able to move approximately 1,000 – 1,800 pounds per trip.

    This note discusses whether there could be superior results had other support mechanisms been in place. Name, if information about total tonnage were aggregated, could the planner have known to slow down end-item delivery and focus on logistics support.

    Also, this note outlines several strategies by which XML-feeds might be integrated to provide support in a disaster support effort.

    Integrating XML feeds into a single area map

    US military planners during the First Gulf War used a system called JPATS to visually monitor the traffic along the road from the Gulf into Baghdad. Also, other GPS systems in Gulf War II allowed US planners to identify the exact location of individual warfighters. The results allowed war planners to align forces to swiftly engage targets.

    This note proposes applying a similar principle to relief efforts. In all probability, logistics planners have a central tracking system allowing them to see where the goods are.

    What it does not appear to have is a system to integrated different relief agencies into a central visual map in a streamlined fashion. This is to say that when an international effort starts in response to an international crisis, the world cannot simply hope that a single organizational body or government can effectively organize all detailed efforts.

    Rather, this not proposes a more automated approach whereby the individual participants, relief agencies, and governments provide through XML their data in re: Relief supplies, shipment times, total tonnage, and types of goods.

    At the same time, this note also proposes that media outlets also provide XML-feeds into this central data-collection point, and the XML-feeds be stripped of their valuable information related to names, locations, types of needs, and other damage reports.

    In short what is needed is a platform that will aggregate the supply and demand data and provide a single picture which all players can see.

    It remains to be seen whether this single system already exists. It may be a matter of simply using a single aggregator. What would be new is a means by which all players would have access to this information and also visually see the disconnects between what is reported as a requirement and what is actually in the logistics pipeline.


    XML feed integration during relief efforts


  • Single map of the relief area
  • Requirements: Relief area requirements
  • Supplies: Relief support material
  • Deltas: Disconnects between the requirements and supplies
  • Bottlenecks in the pipeline

  • This note also proposes that there be an ordering function of the XML feeds. This is to say that during a relief effort there are certain orderly functions. We first provide emergency response before we begin introducing elements required for long-term development. This is to say that we provide emergency food supplies, before we delivering the wood and cement needed to rebuild recreation areas.

    This note also proposes that the XML feed integration effort also have a system to visually depict the various logistics routes such as air, rail, road, and sea. One data set supporting this effort could be the type of information from LandScan.

    During an emergency situation one approach would be to monitor the media information, text messages sent via XML, and other XMLfeed integration, and then strip out the key data such as location, mode of travel, tons, number of victims, and travel times along the various routes.

    The central image would have universally-recognized symbols which end-users could quickly understand to mean: Truck, road, canal, highway, bridge, airport, railroad, mountain, and port.

    This data would then, in turn, be aggregated into composite picture or animation of the area of interest to include distance-time charts, requirements, fuel-time, and deltas between requirements and supplies.

    Reliability

    Also, another analogy for this system would be to have a central rating system on the reliability of the various players and the sustainability of a given logistics effort. This is to say that Charity Navigator provides a snapshot relief agencies, and this type of approach would be useful information for the central XML-integration image.

    The various factors or items of interest would analyze the various elements, players, and travel modes-routes along various parameters useful for logistics simulation, to include:

    - Factors
    - Indicators
    - Relationships
    - Competencies
    - Responsiveness
    - Oversight and reporting

    One common problem with simulating a disaster relief effort is getting reliable information on the times related to travel, numbers, and standard deviations. This aggregated XML-platform would hope to overcome this challenge by stripping out the key data needed for simulations.

    In turn, these simulation results could be applied to program management tools which would properly time the arrival times and sequencing of key relief goods. Simplistically, this means making sure:

  • We get emergency foods before long-term cement;
  • We also have in place the needed travel support before ports become overfilled with perishable food; and
  • There are secure areas for relief supplies, with adequate fuel and trucks in place to transship the goods before staging areas become congested.

    To review, what we propose is simply having an integrated tool that will allow relief agencies and affected personnel a single image of the area of interest. XML feeds could be stripped of valuable information, and this injected into both simulation efforts and program management tools to time the information.

    XML feeds to individual gifting

    The next step is to take the individual case needs and apply the XML feed concept. This is to say that we could use the XML feeds to identify individual requirements and allow individual donors to sponsor individual relief needs.

    For example, a given fisherman on the coast of Sri Lanka may simply have the requirement for a single boat. Rather than have the entire generous world duplicate the requirement and provide multiple gifts for a single need; what could be done is to generalize this information so that individual donors could see the specific end-item they are funding.

    Think of the Amazon.com gift program. The public can set up an account and allow donor to provide through Papal direct contributions to a particular gift. The donors, as if they are using a wedding registry, would like to provide funds for a particular need. They don’t want to buy 12 bipods, when the end-user only wants one.

    So, applying this concept to relief efforts, what could be done in this “single aggregated picture” is to allow the donors to identify specific requirements. Think of E-bay. We have a system of matching both buyer and seller; this is analogous to the market trading programs used in the NYSE and NASDAQ: A buyer and seller are automatically matched.

    This XML feed integration tool would work on the same principle. But also integrate the LandScan information. Specifically, with respect to Sri Lanka, we know we have a single news report of a fisherman who lost his fishing boat. But what we also know from the LandScan data is the aggregate fishing requirements along the coast, the likely number of fisherman, and an estimate of the number of affected personnel.

    Using the magic of statistics and simulation, the XML feed integration tool could pinpoint with precision the likely number of fishing boats that the area requires. In turn, individual donor funds could be supplied to fulfill this requirement. Thus, there would be more efficient matching of relief donor funds to the end-user requirement.

    In turn, the next step is then to ask: How do we get the end-material to the user; what do they need in the meantime; and what other goods will they require to support this effort. This is another way of saying that XML feed integration doesn’t simply end once we throw dollars at the problem.

    Rather, the next step is then to aggregate the information into the composite picture, and identify the specific source of relief supplies. In the case of the Sri Lankan fisherman, the next step would be to identify the physical location of the wood needed to build an intermediate boat; and then identify the route and needed support entities to physically transfer the material to the area of interest.

    The next step would be to identify those personnel needed to transfer the raw material into the end product. When all these steps are completed, we have a single shipment: Funds allocated against a specific requirement; the end-user knows the funds and material are on the way; and the intermediate transshipment points are scheduled based on priority.

    At this juncture, the system has a completed requirement. This is to say that the system now has a valid purchase. Clearly, the reality sets in when the goods have to physically match with the end users.

    This is where the ongoing monitoring elements fit into the XML picture. As the goods are shipped, records are kept of transshipment times, distances traveled, and time goods are sitting waiting. This is key data that can be aggregated so that central planners can identify bottle necks.

    Also, if the end user can see that their need is completed, but they are just waiting final delivery, there could be better planning. The end-user would know that they have X-days before their final requirement will arrive; in the meantime, they can set-up alternatives, and know with confidence that “they don’t have to worry about that, but can focus their energies on alternatives or more immediate needs.”

    In the case of the Sri Lankan fisherman if the “end-user requirement” was to have a fully motorized fishing boat, the aggregated system may say, “We can give you that in X-days; but a more immediate solution might be to use this less complicated workaround such as we provide you the lumber, and also give you training on how to make a wooden boat until the far better motorized boat is available.”

    In short, although the end-requirement may not be available, the end-user could then get alternatives to satisfy short term requirements. This is to say that although the final boat may not arrive for many weeks or months, the intermediate term, there can be a new job order for wood, training, and other materials; in turn, the end-user would then know, “I’ve goat a boat on the way, but in the meantime I could set up a training program with my other fishermen-friends, and we could learn how to make boats and then be on our way.”

    Another alternative would be to show that the real-end-requirement will not be filled for X-months; so personnel in the affected areas need to develop alternative methods to solve their problem. This means that on an individual basis the affected personnel would know that there is a plan in place to address their long-term specific needs, but in the mean time they have some alternatives and options to still get fish: Make a boat, get training on how to make a less sturdy boat, generate some income through less sophisticated efforts, and work with others in the immediate area to create a production work center to expedite the production and manufacture of a large number of individual wooden fishing boats.

    This is not to say that making fishing boat is easy. Rather, this is to simply suggest that rather than wait for the “ultimate product to arrive,” there could be training programs in place to get fishermen to work on small sections of a production line that will get them to an intermediate point. If they can be organized, this will keep their mind focused and more hopeful that there are efforts in place to get things back to some semblance of normality.

    The above scenario may seem extraordinary. But think of the idea of satellites providing real time updates of individual units on the battlefield. Once, it was just science fiction. Now, it is the way things are done.

    The above approach would hope to eliminate bottlenecks, and better dovetail relief supplies with needed logistics support efforts. When funding comes it, it would make sure funding goes to the specific support elements, in the proper sequence, and assist planners in knowing which items need to be prioritized, and which need to be delayed. In some cases, there may be some counter-intuitive shipping priorities: Yes, we need to get emergency supplies, but because we have known bottlenecks, and bridges are out, we may need to ship first large equipment like front end loaders so that bridges could be created to transship critical relief supplies.

    Also, the model would identify those cases were assumed travel routes were out, and alternatives were required, thereby affecting the shipment packaging. This is to say that if the original logistics line was assumed to be a road, but the bridges are out, the alternative may be to get naval vessels to arrive at a relatively small cliff, and have sea-bee type military personnel arrive to physically carve out a new port of entry, and then build a road directly into the affected area.

    Goods that might have survived a monsoon sitting in the airport waiting area might have to be repackaged in a different way if they were to be moved by sea and then transshipped by pack-mule up a steep mud ravine. Goods that might have been packaged as bulk-items on the assumption that they could be moved by forklift, might be broken down at the original-shipment-start-point into individual relief boxes so that they could be easily moved on the backs of pack mules.

    Again, this is not to say that navy units have a superior planning method. Rather, it is to suggest that once the aggregated information can be physically seen, planners might have a better notion of what needs to be shipped, delayed, and how goods need to be packaged.

    We would make sure that the necessary protective gear and packaging required for the worst-level travel mode would be incorporated. This method would also ensure that fuel and trucks and protective gear would arrive first so that subsequent supply shipments could be moved out of the way, rather than create bottlenecks.

    The approach would also ensure there is a logical flow of tasks. Predatory task, start tasks, and closeout procedures would be timed, and planned. The approach would also display alerts when input items were not adequately flowed; or when inputs were out of order.

    A signal would be sent that there needs to be attention on earlier tasks or requirements; and the information would also signal a forecast rate of arrival which would flow into job planning packages to make predictions on the work flow, and identify bottlenecks in the requirements to support the end effort.

    Program Management of XML feed inputs

    In the short term we would focus on what’s needed, doable, and easier

    As time progresses we would work toward the final requirement.

    For example, if the end-user needs a truck to go into the trucking business, we might, in the short terms ensure that there are the requisite support elements to prepare for this final requirement.

    Before we can drive, we need to have fuel; and before we can go down the road, we need t make sure there are places to buy fuel, and also places to physically store the trucks. This simply means making sure that the personnel, if they want to eventually drive trucks, need to have the brooms, shovels, and other hand tools to physically prepare their location for the intermediate equipment that will construct staging areas.

    This system would ensure the fishermen have the tools needed to support the intermediate solutions. We may hope to provide a nice boat; but in the short term, the fisherman may simply need some wood, solutions on how to make rope, and some brooms and shovels to clean out the coast line where they will work. Ultimately, the major replacement item will arrive, but not without many intermediate steps.

    The system would also use a DHL-UPS-FedEx type approach of package tracking. Money and material would be transferred to the end user. XML feeds could be created to create the bills of ladings, and centrally manage the status messages of materials. The bill of lading would give a level of fidelity useful for trend analysis, auditing, and ultimately ensuring the need was adequately met.

    Program management

    The system would identify the individual with the specific requirement, and all intermediate steps to get the package delivered and identify the required delivery purchases of fuel and the needed repairs along the roads and bridges to solve the specific issue; and identify alternative workarounds and necessary supporting elements to physically move the item from the point of purchase to the client.

    The integration tool would flow the work tasks needed to support final delivery and identify:

  • Work order and steps needed to complete the requirement;

  • Physical material and products that have to move and the method of travel;

  • Bottle-necks and disconnects in the requirements and supplies; and

  • Needed changes, and workarounds in the goods delivery pipeline.

    Data would include:

    - Distance
    - Start, stop location
    - Travel mod
    - Fuel, labor, and overhead costs

    Also, XML feeds would be stripped of vital plans and concepts. Novel questions would be identified and flowed into the planning and simulations. For example, questions related to long-term requirements, although a more distant concern, still need to be identified as a valid requirement which ultimately need to be planned for, schedule.

  • Can the plant crops
  • How much salt is in the ground that was otherwise fertile
  • What alternative work efforts can they productively be engaged as productive employment to account for the immediate loss of infrastructure needed to complete this tasks
  • Are we rushing with front end-loaders, when all they really need are brooms and shoves in this isolated area?

    Also, when planning for the long-term efforts, questions may arise such as:

  • If the roads from the northern port in Sri Lanka were originally designed for X-type of travel tonnage, what impact would the additional travel on the existing roads have on the failure of the bridges along the relief effort?

  • What alternative and back-up travel routes need to be planned so that when primary roads fall apart, the back-up roads are there so the primary roads can be repaired and brought back up to the standard to physically handle the increased tonnage and cycles along the bridges?

    This is to say that once the relief efforts starts, the planners will have long-term requirements that may fall outside the core focus of the day to day planners. In other words, its all well and good to have XML feeds providing data on the supplies; what’s also needed is XML-related data that construction engineers can use to analyze what back-up travel routes are needed so that primary travel routes can be repaired without having any impact on the shipments.

    This is another way of saying that the existing crisis can be analyzed in terms of “we know we’re going to have to travel along this route, but this was not planned, so let’s simulate X-number of convoys and estimate when the bridges might collapse; and then let’s plan with adequate lead time so that there are adequately alternative routes in place so that we can ensure the supplies continue to flow from the northern part of Sri Lanka into the southern provinces affected.


    Review


    Current roads not washed out by the Tsunami are not likely designed for this volume of traffic. Need alternative roads prepared with adequately lead-time to ensure there is a seamless transition from the primary road to the back-up travel models. This will allow primary roads to be shut down for repairs, and traffic diverted to the alternative routes, and still ensures the alternative routes can sustain the traffic despite the monsoons and high number of convoys.


    XML feeds for innovation

    Also, during the crisis relief efforts, there needs to be a method to centrally disseminate new ideas and best practices. Again, this is not to say this is not being done. Rather, the aim is to ensure that the central XML aggregator is also used to identify novel solutions to unusual situations.

  • Water kits

    For example, some may realize that desalinization is the major constraint. They may see that although the Indian Army can adequately airlift water, a more viable solution might be to provide kits via air that victims could create that would desalinate the sea water.

  • Osmosis Trucks

    Also, an engineer may come up with the idea of integrating reverse osmosis filtering into a confined space; all that is needed is a sponsor to fund the kit-upgrade to the vehicles. The kit might have a small storage space for sea water; membranes for reverse osmosis; a storage tanks for freshwater; and a storage area for bottles of fresh water.

    Combined desalinization and oil refining

    Another example is creating a single ship which can both drill oil, refine, and conduct desalinization efforts in a safe and healthy way. This ship would carry the equipment, pipes, storage containers and trucks needed to move the end-liquid to the final client.

    Oil tankers could also be modified. Unrefined petroleum in one section, a second section containing a sea-based refining capability, and a third area to store processed fuel. This fuel could then be offloaded to pipes or small boats which could take the fuel inland to the affected areas.

    Edible paper

    Also, there might be efforts to print on edible-paper relief messages, directions, and instructions. Just as you have ink embedded in your checkbook to create a carbon copy, so too could paper be manufactured that has in it embedded micro-capsules of water that would aid digestion. Rather than having to lift heavy bags of water, perhaps foods could be created with necessary water already encapsulated at the cell-level.

    The goal of this XML platform would be to quickly disseminate these new insights so that funding could be allocated to the equipment and produce the end product for the end client.

    Summary

    This note outlined a general concept of integrating disaster information into a central location using XML feeds. The concept relies on aggregating existing information, stripping out valuable data, and then injecting this information into simulators and program management tools.

    This approach would facilitate central planning, minimize duplication, and ensure that relief efforts were coordinated and that products were timed to ensure logical arrival.

    The centralized system would support effective packaging, product sequencing, risk analysis, simulation, program management, eliminating bottlenecks, and identify workarounds. Also, end-clients could be matched with individual donors, and funds could be allocated to similar requirements based on anecdotes.

    Finally, the system would ensure that trends were identified, new ideas quickly disseminated, and necessary long-term alternatives in place to support the overall relief effort.

    We saw that integrated data can be combined during times of battle. We could very well see the same picture during relief efforts.


    " />