EFTA00740930.pdf

From: Jeffrey Epstein <jeevacation(e5gmail.com> To: roger schank Subject: Re: chapter 3/questions for chapter 4 Date: Wed, 21 Oct 2009 14:38:58 +0000 > sorry you are delusional On Wed, Oct 21, 2009 at 10:17 AM, roger schank < > wrote: no need to read this but this dimitri writing to the guy who is putting together a book we are doing together; this is his writing and it seems quiet bright and coherent to me; not from a dope roger schank httplAvww.rogerschank.com/ Begin forwarded message: From: Dimitris Lyras < Date: October 21, 2009 9:43:39 AM EDT (CA) To:" >, Subject: RE: chapter 3/questions or chapter 4 I read some of chapter 3 and I have problems with it. It is too imprecise with regard to what is customarily expected of software and what needs to be done and what we are advocating. The clearly missing issue is that software today covers two main areas. Unstructured information like e-mails and on the other end inflexible process control systems like purchasing systems the most extreme of which is a cash register. So we have discussion means that are completely unstructured, and clerical software at the other end. We also have dashboards like Bloomberg somewhere in the middle. Decision making software is far more structured than e-mails and less inflexible than a cash register and rich in relevance linking which Bloomberg and similar dashboards do not achieve since they do not have activity models. I provided a good explanation before about this. The idea of stories to tell you of similar circumstances is right but the examples need to be 10 orders of magnitude more granular and precise with respect to when and why a similar case is useful. I attach 2 stories that explain this; the power-point explains the problem, the SECOND story PASTED BELOW explains the solution. Form this you can gather that case matching is far more granular than we are describing and far more precise. So the readers will quickly realize we are not in the bed time story business. This is not to say I disagree with bedtime EFTA00740930 stories. I just don't think the readers will marvel at the mention of stories and jump out to change software. For example retrieving a similar story about similar cases of smoking will never convince anyone to change software. The retrieval examples need to be impressive which means precise and differentiated. We need to show a cross contextual example. The smoking example being a cultural thing (an ashtray full of butts purposely placed outside the smoking room) reinforced by the system which retrieved a cross contextually relevant example where crewmembers were detained at immigration for ridiculing the questions in the immigration questionnaire asking of they belong to terrorist groups. Also we use the word context freely without concern for the fact that all the geniuses in the world would take 50 guesses and get the context relevance wrong in most examples. Saying that the ship inspection is in need of context is like saying to an avid amateur stock investor, in a dead pan voice, that any kind of stock picking is in need of Warren Buffet. I have met only Roger who consistently guesses the context and of course he does not bundle the multiple indices of relevance into one word. In short let's not say that all that these reports need is context, because it's actually saying all they need to be good is divine intervention while it sounds like a quick trip to the 7/11 for those that underestimate context and relevance. Why software engineers don't understand usability or relevance is not well explained by Rogers stories of 30 years ago abut command lines. It's is well justified to know nothing about usability 30 years ago and to care about more proximate issue of using computers for the heavy lifting that was deemed feasible at that time. The problem with software engineers is better explained by the fact that today software is an area too broad for the skill sets and specilisations of one category of expert namely software engineer. It's like saying engineer. Mechanical Engineers are more specilised that software engineers. And yet an aerospace engineer will not understand seat design and yet seats are the primary interface with travelers. Likewise a engineer on Microsoft word or Microsoft dynamics purchasing system will not understand relevance. I think we need to establish that Roger is the expert in how the mind works, in education, in AI, cognitive science and in impactful communication. However he does not run enterprises using software and is not familiar with what is around in enterprise software and what the prevailing perceptions are. I run companies using enterprise software and I also build it and sell it. So examples of what makes people pay attention to our innovation should come from me I believe with all due respect to Rogers superiority in the other aspects. EFTA00740931 We need to think how to overcome the lack of sharpness that has got into this chapter. The first story pasted below is a construction business story describing the problem there. it is not important for you to read unless you think the marine story lacks sufficient abstraction to be suitable for other industries. The construction story was written in half an hour. The marine story below it is a real case I personally experienced 7 or so years ago and I have been working on it over 2 years. So it is very rich in the right "natural story" indices for our book. Regards D ON erview of the differentiating principles of the current L'Iysscs R&D; Here we describe the Ulysses R&D work in the context of the 2 domains. There is again a hypothetical construction industry use case, and a hypothetical marine industry use case. The marine use case is also described in the accompanying power-point presentation in a more concise way explaining the problem rather than how it is solved. Below this same case is described more with respect to how it is solved by the Ulysses overlay. They are all hypothetical because we have not installed any software in active sites yet. Construction industry example; Background: (Same as Document management Example) A relief manager from a large contracting company is newly arrived in Brazil to replace the fitting out manager on a project involving fitting out 4 offshore production units at different stages of completion. The fitting out schedule for the current stage of completion is drawn up weekly and updated daily electronically. There are individual team schedules, site schedules and project schedules. The fitting out plans are electronic approved and updated by the local design office every week with a large number of contributing parties on site. Documents showing the schedule of delivery of machinery, hotel and marine installations is held electronically as well as it is regularly updated. Documents showing the rotation of workers and supervisors is also received electronically and update regularly. The supervisors and workers have certain specialisations and are called in at different times when their specialisation matches the particular fitting out process. Cabin technicians are there when cabin units are being assembled, ducting specialists come in when the ducts are being completed. Each new technician on the rig must be trained on certain common training issues and made familiar with certain safety practices. Each team received the appropriate installation plans and diagrams. Each team receives daily updates of the fitting out plan. Each team receives daily updates of delivery of relevant equipment to their particular fitting out work. They also receive information about availability and rotation of staff teams on the rig. Lots of things can change from the expected flow of work and events to the unexpected and it is for this reason that senior managers primarily exist. The right problem to the right person at the right time; EFTA00740932 If a new technician arrives late and cannot be trained on safety issues in time for a job he is scheduled to do, it is some-ones responsibility to adjudicate this decision. However if it escalates it becomes the responsibility of the manager. An entire fitting out stage for the hotel systems in going back three weeks. This does not seem so serious for the hotel system subcontractor since there is does not extend the final date of completion. The on board site manager does not find it so unusual either because it is not in conflict with any other fitting out activity except a statutory fire inspection by the state of Rio de Janeiro. However the senior manager knows that it takes 3 months of lead time to bring in the state fire department in Rio and the next window could be weeks or months away. The fire department has to inspect before the system is finished because they perform some minor destructive tests in unannounced areas of their own choice. So for each role we can see that the concept of importance may be different because they have different processes to co-ordinate. We cannot use workflows to direct every expectation change to every senior manager otherwise senior managers would do nothing but read minutia of questionable importance to them. Also elements of reports need to be seen in combination otherwise it is difficult for a senior manger to determine the degree of considerations that have been taken into account. For example the senior manager needs to see what potential workarounds have been considered for the hotel system fitting out delay before getting involved. Furthermore the higher the position or the more the user is mobile with his hands full, the less he will be able to run through an enterprise system trying to string together elements of the same problem relevant to his stake-holding. Also the larger the enterprise the less one knows about who else is affected by an expectation change. For example the cabin fitter needs to know that there is a series of alarm tests in week 24 at various times so as not to confuse them with safety alarms. The winch installation supervisor needs to know the exact launch movements during the day when he is has expensive specialists and inspectors on board and needs to co-ordinate them with weight tests. The welders need to know when the cabin gangs will be out of the way to ensure that the plates behind their work can be accessed in case of fire and the painted after burning. None of these people can go around laptop in hand going through even the most tailor made application. They need a system that finds how events become relevant to their own stake-holding and this needs to work primarily with a handheld device. 2; Maritime industry example. A noise is heard in the main engine of a vessels; how does the Fleet Manager co-ordinate a solution using the overlay? The Fleet Manager (FM) arrives at his desk and logs into his system. Yesterday afternoon, he was dealing with a crew situation on the Chimera, so he was expecting to continue dealing with that to start his today; the screen shows his "Situation Room" (a screen in the Ulysses overlay) where he left off with that issue. And then he knew there was going to be a status meeting the next day that he needed to do a little research for, which he'd get to after addressing the crew issue. But something has changed on his screen. At the top of his list of Risks, he sees a flashing report of an observation on the Pegasus. His map has a pulsing red dot, indicating the location of the Pegasus (in the EFTA00740933 Malacca Straits). The Chimera problem has been dropped to 2nd on his Risk list, and the impending status meeting drops to 3rd; the system knows that a potential mechanical problem is more urgent than addressing a crew problem or a status meeting. The primary reporting source was the chief engineer: A technical observation was registered by the chief engineer of the Pegasus. The chief engineer assigned the immediate effect to ships main engine safety and propulsion capability as the primary indexing step. I. The observation is noticed by the immediately responsible party who mentions it and assigns it to what he considers it will affect. 2. The process he mentions and the observation description are enough to attract the attention of all the right participants. In the overlay environment with thousands of participants, someone escalates this issue in one step and after this single step, several up to thousands of participants an be appropriately informed. 3. Further discussions amongst the relevant roles must take place and these must be visible to all participants. 4. Trusted participants must be able to take remedial action as they see fit with co-ordination of major action taking place under the direction of the role related to the processes being enacted. For example the ship can be stopped by the Chief Engineer and Master when the noise is determined to be dangerous by his own judgment, Or the Fleet Manager for whatever reason provided the situation affects the processes for which he is responsible. Shared discussions: Through his screen the FM also notices that the superintendent of the Chimera, who was dealing with the crewing issue, is now involved in a risk discussion about the Pegasus, too. When the FM sees what the superintendent is doing he goes over this Risk discussion which he has access form his screen. He gets a little bit more detail to give him an idea of what the observation was about: A noise in the no 6 cylinder of the main engine, made by the chief engineer. The system indicates that there's an on-going discussion about the immediate and potential risk. The FM agrees to join the conversation (as opposed to delegating his responsibility to someone else or ignoring the conversation for now). The Fleet Manager definitely has another situation on his plate, which he now sees in a more prevalent way in the "Situation Room"—the main area of the screen. The old situation he was working on (the crewing issue) gets pushed aside, in favour of showing all of the relevant details about the Pegasus situation that have been collected by the system—for example, Links to the commercial commitments of the vessel, last port of call, next port of call, links to the details of the observation, a list of the people involved in the conversation so far (and those who have been invited), and vessels within the company that have the same engine. The system provides additional assistance in assessing the situation: Alternative approach with conventional systems: • In a conventional system he would need to have the observation channelled to him. He would have to hold meeting to determine what is being discussed regarding risks and causes. Unless the subordinate staff thought it was a matter that could affect the ship commercially and technically in a serious way, days may pass before the Fleet Manager would be informed. As for related information like contract commitments once he is aware of the event and potential gravity he makes a search for the carter EFTA00740934 contract overview to see when the contract specifies its time limitations lay-days/cancelling, and he walks about the office to find out who is involved or calls them, looks at the technical defects of similar vessel to locate defects on the particular main engine. If he is on a trip of he would have to have a subordinate pass all relevant information. INVESTINGATING THE TECHNICAL AND COMMERCIAL ASPECTS; The main screen has 4 choices only and can be navigated on the move or under the mist unaccommodating circumstances. • His main screen highlights the processes needing attention. Perhaps only three to 4 processes. That is all he will see. This can be accommodated on a handheld or navigated even during a meeting or in a taxi. Clicking on each one takes him to event related discussions by his subordinates. So far the processes are "main engine operation of the Pegasus", " Shell Charter of the Pegasus", " relationship with charter Shell" , "ships profitability Pegasus" clicking on any of these processes will bring up current company discussions about how this can escalate, what could be the cause, what immediate remedies are available etc. Related processes to the ones immediately at risk within the main Task Assistant; • The Fleet manager will access the current discussions and from the overlay. When he is in convenient circumstances he will be able to be shifted to part of the task assistant that shows particular relevant details. Functions such as machines with similarities sufficient to assess the current situation in case something similar has happened to another vessel with the same main engine. He will also need to know commercial issues concurrently because the conventional technical investigation seriously interferes with commercial commitments. In a conventional system; • No system that we know of will highlight the processes at risk. So the user must make this relevance association and then recall data and documents that could be related. So the user can access a conventional planned maintenance system for specific objects he knows may contain information relevant to these processes. This cannot be done on the move or without a laptop at least and with a great deal of practice using the variety of applications. He or his subordinates need to search for engine overhaul calibration sheets specifically, engine defects specifically, cylinder unit assemblies for overhaul purposes and for potential reasons for the noise etc. The superintendent also makes these specific searches as does the chief engineer. The FM also looks at commercial processes and sees correspondence via emails with charterers, previous correspondence with charterers on this vessel. The operations manager looks at charts for safe anchorages along the route and may want the Fleet manager's opinion if the ship is to wait in an anchorage without power while an overhaul takes place. Previous experience is paramount in these cases too. Similar cases provide the primary means of reminding for better decisions. Similarity is a relevance issue and is just not addressed by conventional systems. For example a similar case is needed to remind people that a remote anchorage without tugs in a place where weather patterns are unpredictable, can be disastrous. A similar example for the main engine noise is a very fine concept needing intense relevance modelling. Finding all relevant material could be very time consuming and will not be done. Any such work will be done by recollection via a colleague in this case the chartering manager. CONTINUING THE TECHNICAL INVESTIGATION: Relevant information updates: EFTA00740935 Before calling the Superintendent, the FM takes a look at the details of the observation via the "Situation Room" screen , indicating a noise in the 6th cylinder. There's a follow-up comment by the Master, accessible in the Situation Room, that indicates that the chief engineer has reduced speed which could put the vessel behind schedule. This is immediately directed to the chartering managers processes under voyage performance and also the equivalent process for the Fleet manager. So the master's message is now part of the Fleet managers process "Shell carter of the Pegasus". Being able to see what colleagues are actively doing about the important current events; The FM then wants to call the Superintendent, noting on his screen that the Superintendent is already in a risk discussion regarding the Pegasus. He sees this in his Operations Centre screen, where he can see his direct reports and other important people around him, as they relate to the situations he's dealing with. The FM calls the Superintendent, who happens to be in a conversation with the Superintendent of the Chimera at the time; the Pegasus explains that the system suggested the Chimera be involved in the conversation because of the experience of the Superintendent and of the similarities between the Pegasus and Chimera (notably that they have the same engine but an earlier design). Unfortunately, the Chimera doesn't have any direct experience with a problem like this, but his sense is that it's not something that has to be addressed sooner rather than later, given his general experience with the Chimera and other similar vessels. The process of monitoring machinery for senior office roles brings experience of similar machinery on other vessels through the TA which has machinery information independent of installation. Overlay categorises information by risk and cause enabling special highlighting of risk; While they're discussing the problem, the Superintendent refers the Fleet Manager to the PMS and performance data provided by the system. The PMS indicates that the vessel had a breakage of an exhaust valve, but no root cause was assigned, but all exhaust valves were checked for cracks, so the Superintendent isn't too suspicious that this is the same problem. He also notices that within 2000 engine hours the exhaust valve stems are due for replacement. This last requirement is unusual, but the superintendent does not give it much attention. The Chief Engineer suggest that, given the faintness of the noise, even if they stop, they may not be able to find the problem anyway, so they recommend continuing into port and dealing with the problem later. The grouping of relevant events by process enables highlighting of past problems that could exacerbate the current situation; A risk discussion with the chartering manager in a risk discussion format raises the issue that should they stop, the charterers and brokers will surely consider the vessel as having serious machinery problems since it had such problems with the previous owners. So we are facing a serious risk of a client relationship problem. Using a conventional system; • The superintendent checks the defects, calibrations and maintenance records of the Pegasus and also of the sister vessel. Without having them indexed by root cause and risk it is time consuming to locate the relevant ones because the main engine can have many minor defects. If this search is extended to more than 2 vessels perhaps because similar may have been reported in other engines, this will be prohibitively time consuming. The FM is inclined to agree with the opinion of the superintendents, and with no imminent threat of any major problems on the vessel, decides it is safe to leave the office for the day. RECONSIDERS THE SITUATION: EFTA00740936 When he comes back to the office the next day, he sees where he left off; this isn't a system that forgets what you were doing and forces you to reset your own context. The system understands aspect of risk that people may overlook; He still has details available to him about the situation, and he also sees that the Superintendent is no longer in a discussion about the Pegasus; the situation is also indicated as less urgent, given notes made by the Master and Chief Engineer about their current course of action. But the FM still sees that the system is still offering high-priority advice about serious risk to machinery, and to ships profitability , because there are 2 unresolved defects, while the current noise is an unresolved observation. The QM also points this out to the FM and says that while there are other unresolved defects on many other ships, on the Pegasus in this noise in engine observation there are 2 previous unresolved defects in the same and all three affect very high level concerns such as machinery integrity and profitability of vessel. So the FM checks the system's defects that this type of engine has had. On this vessel he confirms that engine had 2 problems that had minimal or no warning signs and which were never assigned a root cause, which is why the system raised these cases as thematically relevant in a situation where there was an unknown root cause. In a conventional system: • He would have never be reminded that the defect had no root cause and neither would the Quality Manager. He would have to read every defect that has no root cause and there may be many, and see if any of them were still missing root causes. The overlay links the defects without root cause to the processes they endanger and the parallel observations which when coinciding impose major risk. This is not possible with a system that does not have an activity model at its core. Now armed with the FM's input, the Chief Engineer is more suspicious that this engine could be suffering from this kind of problem, and what he thought was an unlikely connection to the exhaust valve is now far more likely. This adds a logistical aspect to the repair because of the need to get the specialist on board. A series of discussions is made regarding commercial issues related to the potential remedial action: • The Fleet Manager and the chartering manager discuss in dedicated risk discussion formats, whether there is a risk of endangering the vessel's reputation with charterers by stopping. The history of this vessel with charterers is relevant as is the relationship history of the company in general with these charterers. A similar situation is considered as regards the brokers, who may use this episode against the vessel in the future when working for another client. • The FM and Owners and the chartering manager also have a discussion about the trade off of potential damage to the main engine, the potential damage to the ships reputation with the charterers, and the loss of the current fixture which may result in the vessel fixing another business at a lower rate while also incurring waiting time. The risk discussion about the chartering situation helps link any potential propulsion issue to the commercial income and reputation related issues. This means that for this vessel the system will now show the chartering manager the risk of potential commercial problems emanating from propulsion issues whenever he is planning a fixture, while the owner will be shown the potential cost of this type of propulsion machinery when selecting a vessel for purchase. • The FM discusses with the Ops manager whether there is a safe anchorage where a specialist can also attend or whether there is a port where the specialist can attend and sail with the vessels to an appropriate anchorage. The latter allows the specialist to hear the noise and comment on it. ORGANISING AND MONITORING THE REPAIR: EFTA00740937 The group agrees that this is the appropriate course of action. • The FM sends a request to the Superintendent to initiate remedial action and the Chartering manager, Operations manager QM and FM discuss the details of where and the potential safety related contingencies. • A risk discussion/analysis is made regarding the repair itself. The repair involves some opening up and the processes highlights additional minor defects to some of the hydraulic overhaul tools. The chartering, QM and Ops manager, of course, have been aware of the conversation the whole time; they have their own view of the Pegasus situation on their screens, so when the request to make the repair is made they can see the building history of what has been explored and what the FM is recommending. While the Ops manage the Super and the QM initiate the remedial action, the FM can continue to see who is handling what, via his Operations Centre. (If any risks arise in the course of the repair, the system would raise these for the FM to address, but otherwise, the Pegasus situation would persist in the Situation Room until it is resolved.) For example if the anchorage is safe during the day but prone to dangerous winds at night a new process is highlighted in the situation centre at night. Further potential causes to the noise discovered by the overlay; As the superintendent investigates the relevant past experience with the main engine, the system points him to manufacturer's circulars. The overlay knows that one of the most prevalent causes of unexpected conditions in machinery besides following maintenance schedules and manufacturers recommendations when they are not obvious, is that the manufacturers design has shortcomings. Design shortcomings are often accompanied by strange recommendations that seem at first to be founded on the manufacturer's interest to sell services or parts. The overlay will point to processes prone to this problem and will also recall similar examples with other machines. It will recall some strange and emphatic recommendations by another manufacturer to change main engine fuel nozzles to as design that perform better at lower speed without explaining that the previous nozzles were actually causing damage at lower speed. The experience of this damage was recorded as a case 5 years earlier and the cryptic recommendation was an example of this conflict between manufacturer and client when the design has flaws. The system also highlights a similar case about a boiler malfunction after repairing the furnace tubes from 7 years earlier. This case came under under the more obvious prevalent problem in machinery maintenance, of not following manufacturer's instructions. Given these reminders the superintendent looks through all the manufacturer's circulars and finds one that inexplicably recommends that exhaust valves are replaces at 40,000 hours. This is not applied to inlet valves and is not a recommendation any other manufacturer makes without qualification to particular condition indicators. Furthermore the inlet valves are not given a finite life and there is no conditions discussed. He recognises this as a design problem cover up and mentions it in the cause discussion with his colleagues. He also goes through all the manufacturers recommendations for measurements and clearances in case one of the recommendations has not been followed. He notices that exhaust valve stem clearances are slightly larger than recommended. He also notices that there are no valve guide sizes that when replaced will reduce the clearance as in most engines. In a conventional system; Conventional systems do not have activity models so there is no way to index cases across context. Such a system would never relate fuel nozzles to exhaust valves and boiler furnace tubes. If the fleet manager were not present in all these cases no one would recall these fundamentally relevant cases from different ships and different machinery. And even if the Fleet Manager was experienced perhaps he is not an engineer and his experience is focussed on marine side issues. Remedial action is underway; The ship proceeds off the port of to Malacca and picks up the specialist. The vessel then proceed for a few hours and the technician finds the noise to probably be related to the valve stem clearance which in turn is related to the valve stem running hours. This is reported to the office on the root cause discussion EFTA00740938 format. The FM and superintendent are more confident now in stopping the vessel given a probable root cause discovered by the superintendent and supported by the specialist. The anchorage selected by the OPS manager is found reached and the valve stems replaced in the no 6 cylinder. The vessel proceeds again on trials and the noise is no longer heard. It is then concluded that the noise was due to valve stem clearance and that probably the valve stem breakage of a few months ago was from the same cause. The root cause In a conventional system: • Scenario 1: There is a series of meetings to discuss the above issues. Since little if anything is recorded, none of this information serves to assist in the future except in people's memory. This is because instead of the risk discussions taking place in an asynchronous manner in written form where people can take the time to confirm and support their views by referencing information, they take place in meetings. The meetings are disruptive and people are rushed to take decisions governed not by the degree of exhaustion of relevant issues but by the personalities, agendas and other engagements of the attending staff. Also people may forget to mention items such as comments made by charterers about the vessels machinery in a previous communication through a broker. This kind of information can be critical to the reputation of a vessel especially when the vessel is due to stop again. • Above all there would be no recollection of cases that were relevant across context. KNOWLEDGE MANAGEMENT: After all is said and done with the repair, the system now has a new set of stories for the corporate memory. • The next time someone makes an engine-related observation that could have a significant impact on performance and voyage, the system will be able to offer the additional story of how the company handled the Pegasus, as advice. • The cause of this observation is allocated to valve stem running hours and the purchasing system and maintenance system will show this observation in the valve stem components. Vessels with similar main engines will also show this. • The root cause of this observation is allocated to two of the most familiar causes in engineering. Not following the manufacturers clearance recommendations, and the manufacturers cryptic cover up of a design flaw in the valves stems, indicated by unusual recommendations to replace the valves regardless of condition. • The next time a repair needs to be done in the Malacca Straits, this repair would be raised as potential guidance for who (or who not) to do the repair, based on the experience recorded in the system. • The entire repair process could be relevant to anyone proposing a similar repair in anchorage (not just at that particular port). • The entire episode will be accessible to the next crew on the Pegasus—not just the observation of the cylinder noise, but how it was handled and what the outcome was. • The chartering manager might want to know that the Pegasus ran into mechanical issues when contracting the vessel for its next voyage (if the voyage is particularly time-sensitive, for example). He may want to know for example when the running ours of the valve stems are close to the limit on the Chimera. EFTA00740939 • The owner needs to know the potential commercial disadvantage or direct cost of a vessel with this type of propulsion machinery. All of that is potential advice that can be offered in future related situations. In an alternative system the means to arrive at the above knowledge would be as follows: • There will be no way to distinguish from defects affecting propulsion than defects that do not. So all main engine defects including compressed air reducing valve adjustments, fuel piping, control air piping, maneuvering, cylinder surface scratches, piston ring breakages etc will all need to be read. But when? Whenever this ship is chartered on a tight cancelling? • Defect cannot be searched for specific root cause other than a managerial root cause such as technical latent defect or maintenance which is far too broad. So the valve stem sensitivity to running hours will not be highlighted unless one reads the particular defect. Customary root cause analyses on conventional systems do not include indices of vessels specific components and activities because the system will need to include these in a configurable model for each vessel and customer. What is more even if the model exists in a special defect reporting application; • How will it come to the attention of the purchasing manager who has to order the valve stems for the Chimera in the future when its running hours reach 35,000? • How will it warn the next chief engineer and the superintendent of the similar vessel? • How will it warn the chartering manager in situations where cancelling is tight? • How will it warn the owner when he values a ship with a similar main engine? • Above all how will cross contextual referencing to experience be achieved which is the primary tool in problem solving and decision making? From: Irma° Sent: 20 October 2009 20:31 To: ; Dimitris Lyras; Subject: chapter 3/questions for chapter 4 Attached is chapter 3. A solid chapter, but again, pay particular attention to the examples and feel free to revise or suggest other ones. Dimitris, your examples were great, but I took some license with them in order to make sure they dovetailed with the chapter's key points. Dimitris, Elliot, here are the questions for Chapter 4 and the chapter description from our outline; Roger, let me know what day/time is good this week for a call so you can answer the questions: Chapter 5—IDENTIFY AND DESIGN AROUND THE PAIN POINTS 1. This chapter is about helping readers figure out where their decision-making problems are. Or rather, the decision- making issues that are most crucial to address. Perhaps you can start out by discussing what are the most common decision-making difficulties organizations face. Speculate on types of tough decisions from top to bottom of an organizational chart. What are the three or four most challenging decisions for CEOs and other senior leaders? What are the toughest decisions for the typical middle manager? What types of decisions are particularly hard for line workers, for people charged with getting things done whether in customer service, finance or marketing? EFTA00740940 2. Why are these decisions so tough? Is it because they involve goal conflicts—if so, can you suggest same typical goal conflicts that organizational employees face? Or are decisions also difficult because they must be made immediately? Or because there is a lot riding on the outcome of those decisions? Or because they must be made in the heat of bathe and there's no time to reflect and consult others? Or because there's a great deal of ambiguity and uncertainty surrounding the decision? 3. Can you talk about some examples of pain points in the shipping world (the chapter description talks about accidents)? What are the five most difficult decisions a captain or other shipping leader faces? Why are these decisions so difficult? 4. Once you've identified the pain points, is the next step identifying the activity model related to these pain points? How do you create such a model? What do you need to know to do so? What questions do you need to ask so that you can map an activity of a given individual or area effectively? 5. How do you translate all this into software? I'm not asking for the technical process as much as guidance for readers about what to do with the information in a higher level sense. For instance, how does knowledge about pain points and activity models translate into software that helps people make better decisions? Perhaps you can answer this question with an example—take a particular pain point and activity model and demonstrate how it helps create software that assists people in making tough choices? 6. Contrast the pain point/activity model software with typical organizational software. In other words, does most organizational software ignore the tough decisions people face in companies? Does most organizational software ignore mapping activities? Why do they ignore these issues? Is it because they don't understand cognitive science? Is it because they're so locked into providing their people with information? Every company has pain points—teeth-gnashing, hair pulling problems or obstacles that make decisions difficult. They may involve goal conflicts where you want to introduce a high-quality product with a bang yet need to find a way to split a limited budget between marketing and manufacturing. Or it may involve the war for talent—you find yourself losing your best people to competitors or unable to attract the best people to your organization. All sorts of challenging decisions revolve around these pain points: Should you pay more to hire highly talented Joe and upset the salary structure in a given department? Or: Should you invest the money necessary to bring out an innovative new product knowing full well that knockoffs will appear within the year and you'll lose your competitive advantage? Every industry and every organization has its own particular set of pain points. By identifying them and creating software with these tough issues in mind, you can prepare decision-makers to deal with them effectively. For instance, in the shipping industry, we know that accidents happen in certain conditions. Therefore, good software would alert the ship captain that these conditions are about to occur and that he should consider alternative plans: "We know it's raining, that it's dark, there are icebergs and you're crew are tired; you might want wait at the anchorage before proceeding in the morning" The information contained in this communication is confidential, may be attorney-client privileged, may EFTA00740941 constitute inside information, and is intended only for the use of the addressee. It is the property of Jeffrey Epstein Unauthorized use, disclosure or copying of this communication or any part thereof is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by return e-mail or by e-mail to jeevacation@gmail.com, and destroy this communication and all copies thereof, including all attachments. EFTA00740942