5. FOCUSING ON THE ANALYSIS PROCESS
Chapter 5 establishes the bound of the study at the Analysis phase of the process. Doing this, it will be possible to achieve a valuable result with the time and resources available. For each problem highlighted in the previous phases, a solution and improvement will be suggested. Moreover, keeping the Analysis phase as refer point, a list with all and only the Critical information has been produced, and it will be used as starting point for the following operations.
For each point highlighted in the previous chapters it is possible to set a solution or improvement. The project will take place in six months, and this amount of time is undoubtedly not enough to analyse and improve all the processes necessary to gather the parameters. Therefore, which stage of the process is more useful to give attention to?
The areas underlined as points A, B, C, D, E are potential points of action. At this stage it is necessary to chose which area the analysis, carried out by the candidate, has to focuses on, so that the available time can be concentrated to complete, at least, one task. So, now, is necessary to establish exactly the bounds of the study.
To make this decision a data control team meeting has been settled, where the outcome of the previous activities has been explained. During the meeting, each member has expressed his opinion about the point where is necessary to focus on in order to take full advantage from the analysis process.
The team believed that concentrating the study in the analysis area a valuable result can be achieved with the time and resources available.
For this reason, from this stage onwards, the study will be carried out from the Analyst point of view. This means that this phase of the process will be the refer point for the following actions.
After that this decision has been taken, and a point of view clearly established, an unambiguous definition of critical parameters can be provided: Critical parameters is the information, held on any possible support, without of which the analysis can’t carry on.
Must be clarified that the state of critical is not absolute but changes with the running of the contract. This means that a parameter can be critical in some stages of the ILI process and not in others, because it has got a different level of criticality depending on the point of the inspection process where it is.
In Figure 23, the concept map developed in the first stages of the project has been added with the new information acquired.
First of all, a more depth analysis of the analysis phase is required. The analysis process has been fully explained within Chapter 3; in this chapter instead, the focus is given to all the parameters used in this phase and their source.
Figure 1 Concept map of the task at stage 2
The first action undertaken by the candidate is to create a list of all the parameters needed for this part of the process and to analyze their source. To do that, the analysis phase has been split in sub-process like shows figure 24. This subdivision is the outcome of several interviews with Analysts and Project Leader.
Quoting the instance for MFL, the average elapsed time of an analysis, usually, is 28 days. The length of each section in the graph is proportionate to its length of time. This means that, usually, the production of the preliminary report lasts around 15% of the total time, the boxes editing 60% and the production of the final report 25% of the total time.
The important information arising from this graph is that, knowing whether a parameters is needed at the stage A, B or C means to know that the time available to gather it is 0, 4 or 17 days. Figure 24 includes the Data Control phase as part of the Analysis phase. Actually, the Data Control phase, is an independent function and the analysis activities can’t start if the data control activities are not ended. Because that these two functions are closely connected, data control phase has been included in the following analysis with its sub process Data Preparation and Data Processing. From this point on, the term Analysis phase will be used with the meaning ‘data control and analysis phase’.
eDelivery, as briefly described in Chapter 2.4, is where the Analysis phase find all the needed information; studying this phase is, thus, inevitable to mention it.
5.1 eDelivery for Analysis Phase
eDelivery has already been presented in several parts of this text but here the explanation will be focused on the parts used by the analysis phase.
Figure 3 eDelivery screen of the main menu
eDelivery is utilized for Analysis with two main purposes:
• to insert information about the tape and the running of the analysis and • to consult information to carry on the analysis.
The area where analysts have to fill in information are in eProject – Data Analysis – Data
Analysis (as shown in blue in figure 25). As regards the consultation, the information is
Figure 4 Screenshot of AR and AR Excel Report
However, a big part of the parameters needed by the analysts are present within the eDelivery section called Analysis Requirements, located in eSales – Customer Requirements – Analysis
Requirements.
This section is filled in automatically by the system, using data from the PQ, and manually by the ComOps during and after the BID phase.
The Analysis Requirements Section is made up of some Tabs. The first tab Contract
Deliverables is common to all the technologies and it contains information about the client (as
the address to receive the report and the contact for any necessity). The following tabs are different from technology to technology and they contain information about the pipeline and the product flowing inside it.
Especially for the minor technologies, but for the brand-new one as well, there is not a dedicated AR section, this means that the structure created for another technology must be used as better as the users can to insert the data. Sometimes an AR apposite section exists, but it has not been modified with the technological development of the technology itself and it does not answer anymore to the new requirements.
The Analysis Requirements Report is accessible directly from the Data Analysis Section, using a linked button. Pressing the button, an excel report will be produced (see Figure 26). However, the report does not contain all the information in AR but just part of them. Moreover, some data in AR appear different in the report, or even missing. These issues will be faced up in Chapter 6.
As explained above, Cramlington is the headquarter and the refer point for all the MFL inspections. The other technologies are processed and analyzed in other sites. In order to cover, with this project, all the technologies adopted by PII it has been necessary to tackle with
employees from others sites and other countries over the matter. In spite of the big distance, the cooperation with the others sites has been carried on by meeting calls, screens sharing, emails and using the intranet communication system. This has not always been easy but very useful in order to study their requirements and their necessity.
From considerations above, emerged that a good solution to implement, improving the process of collecting the needed parameter, could be fitting the AR Report to the requests of the analysis phase, for each different technology. The purpose of this action is to offer to analysts a place to look for all the needed information, saving time, avoiding errors and missing information. To undertake these purposes, first of all, it is necessary to understand what, inside eDelivery, is critical for analysts and what is not. To do that, each field has been highlighted in the eDelivery tabs used by analysts. This operation has been developed for each technologies and, though the following explanation is referred to MFL, the same path has been followed for the other technologies.
5.1.1 Review of the eDelivery tabs for Analyst
The candidate has produced a report showing all the fields in eDelivery used by Analysts. Moreover, in the report are highlighted the fields that the analyst has to fill in and, for each parameter, if it is critical from the analysis point of view or not. This difference has been drawn to attention by using different colours. Finally, for each highlighted field has been shown the responsible, that is the person accountable to fill it in. The analysed sections of eDelivery have been:
• eSales – Customer Requirements – Pipeline Questionnaire • eSales – Customer Requirements – Analysis Requirements • eProject – Data Analysis – Data Analysis
• eProject – Resources - System Settings
Figure 5 eDelivery Tabs for Analyst Report
The same outcome has been presented in a list called Critical Parameters list. This list has played important role and it has been explained in depth below.
5.1.2 The measurement phase
Once established the direction to move toward, an analytical analysis to support the decision taken is necessary. The following phase consists, thus, in a measurement of the amount of missing information.
The sizing of this quantity is held furthermore, to understand useful information about the needed parameters. For instance, if a parameter is often missing, this requires further investigation to understand the reasons of this behaviour. Probably the parameters is not critical as thought, or it is hard to procure, or the problem is about the form used to gather it, maybe it is not clear, or the field is called in a different way from the parameters. The causes can be several and once they are known, it will be easy to work out the most suitable solution.
The measurement phase is started after the first month of study and it will continue for all the remaining months. The aim of this activity are to carry out, on the first stage, a measurement activity and, on the second stage, a monitoring of the changes made. The result of the metric
will be transmitted monthly by the candidate during the Data Control Team meeting for the update of the project.
To conclude, the measurement phase is necessary to have an analytic view of the significance of the problem. Finding a way to measure some of its aspects, it will be possible to control them. Moreover, a clear definition of the entity of the anomalies can help defining objectives and monitoring the advancements done. This idea has been developed with the following worksheet (already existing) and the one illustrated in Chapter 6.1.
Project Manager to Analysis Worksheet
The metric is called PM to Analysis worksheet because it is measuring the performance of parameters coming from the PM and needed to Analysts so it measures the missing information input of the analysis phase. The PM is considered as the only source of the parameters because during the HandOver Meeting, PM should verify that the documentation handover by ComOps contains no missing information, and, in this case, he should contact the client and ask for them. Moreover, PM is the person strictly in touch with the client and with the wider view of the contract. For these reasons, the handover meeting can represent a checkpoint and PM is the right person to be accountable for missing parameters.
On the other hand, he should reject the handover of the contract if too many parameters are missing in spite of the due date of the inspection to avoid delay and the payment of penalties. The worksheet has been built so that the number of parameters can be automatically counted. The responsible to fill in the metric is the Data Controller on the moment of receipt of the Tape. The first page of the worksheet (see figure 28) contains an explanation about how to fill it in. The second page of the metric is structured like shown in figure 29.
About each contract, the responsible has to insert number, Region where it is located, date of the first run and the technology used on the field. The last information is necessary because the same contract number can refer to more than one technology, as the case that the client asks for Mapping and MFL inspection together. The three lines on the bottom show the results of the worksheet and their meaning is explained below.
• Missing H eDelivery Information from PM and Field Documentation, this line shows, for each field tech utilized on the contract, the number of missing parameter categorized as H in the previous activity.
• Missing L Information from PM and Field Documentation, this line shows, for each field, tech utilized on the contract, the number of missing parameter categorized as L in the previous activity.
• Incorrect Information found in PM/Field Documentation, this line shows, for each field tech utilized on the contract, the number of information in eDelivery that are different from the same information on documentation from the Field crew.
Figure 7 PM to Analysis Metric
The graph in figure 30 shows the results of the metric run for the months of November and December. During this period, 73 MFL Inspection Runs arrived and logged with F2A Metric.
It is clear looking at the graph that Cramlington site has got the highest number of inaccuracy and that an effective action to solve this issue is required as soon as possible. The reason of the huge difference between Cramlington and the other sites could be several, but the Data Control Team has identified that one of them may be the different typology of form used to transmit information from the field to the analysis centre.
5.2 Critical Parameters List for Analysis Phase
The results shown by the worksheet confirms the necessity of actions in the direction highlighted in the previous chapter. The Critical Parameters List (CPL) for Analysis Phase created in the chapter 5.1.1 has been taken as starting point for the following actions. Owing that List is possible to get an updated list about all the information in eDelivery needed for processing or analysing data. This list is the base for following activity and must be constantly kept as reference to find a procedure for managing the parameters contained in it.
Firstly, in order to build the list, all the parameters contained within the locations listed before have been considered, in order to avoid that important information could be missed.
Secondly, the parameters have been selected and, finally, they have been categorized. Therefore, the Critical parameters list is the result of the following steps performed by the candidate:
a) All the parameters included within the locations listed in the chapter 5.1.1 have been written down.
b) Each parameter has been classified with Y or N if it is needed for processing or analysing data or not. 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 1 0 7 1 5 0 -1 6 A 1 0 7 1 3 7 -2 6 B 1 0 7 1 4 2 -0 8 E 1 0 7 4 0 0 -1 6 A 1 0 7 0 8 7 -2 0 C 1 0 6 9 8 3 -1 2 B 1 0 7 1 4 2 -0 8 D 1 0 7 0 4 9 -3 0 H 1 0 7 1 3 7 -2 6 A 1 0 7 0 4 9 -2 6 C 1 0 6 7 3 4 -3 0 J 1 0 7 0 8 7 -2 0 A 1 0 6 8 4 7 -0 6 B 1 0 6 7 3 4 -3 0 F 1 0 4 8 0 0 -1 6 A 1 0 6 8 4 7 -0 8 D 1 0 6 8 4 7 -0 8 E 1 0 5 7 2 8 -0 6 A 1 0 6 3 2 5 -2 0 A 1 0 6 6 8 2 -3 6 E 1 0 6 6 8 2 -3 0 C 1 0 7 0 8 7 -2 4 C 1 0 7 0 8 7 -2 4 D 1 0 7 1 4 2 -1 2 A 1 0 7 1 4 2 -0 8 A 1 0 6 6 8 2 -3 0 G 1 0 6 7 3 4 -3 0 E 1 0 6 7 3 4 -2 6 A 1 0 7 1 4 2 -0 8 F 1 0 7 1 4 2 -0 8 B 1 0 6 9 9 1 -1 6 A 1 0 7 1 4 2 -1 0 C 1 0 6 6 8 2 -3 0 F 1 0 4 2 4 7 _ 3 6 G 1 0 3 3 8 0 _ 1 6 D 1 0 3 3 8 0 _ 3 6 A 1 0 4 2 4 7 _ 2 0 B 1 0 0 2 7 6 _ 0 8 D 1 0 2 9 9 5 _ 1 4 F 1 0 2 9 9 5 _ 1 6 D 1 0 5 7 7 4 _ 0 8 A 1 0 5 7 7 4 _ 0 8 B 1 0 7 1 7 0 _ 0 6 D 1 0 6 4 4 1 _ 1 0 B 1 0 6 4 4 1 _ 1 0 C 1 0 6 4 4 1 _ 1 0 D 1 0 6 8 0 1 _ 2 4 H 1 0 7 4 9 7 _ 1 0 A 1 0 5 2 5 5 _ 3 6 A 1 0 6 8 0 1 _ 2 4 J 1 0 6 8 1 9 _ 2 4 D 1 0 5 4 3 9 _ 1 6 A 1 0 6 8 0 1 _ 4 8 B 1 0 6 8 0 1 _ 2 4 G 1 0 5 0 6 8 _ 2 0 B 1 0 6 2 6 4 _ 2 4 C 1 0 6 4 0 6 _ 1 6 A 1 0 5 4 3 9 _ 0 8 A 1 0 6 8 0 1 _ 4 8 C 1 0 6 8 0 1 _ 1 6 C 1 0 7 4 4 1 _ 2 0 A 1 0 7 4 4 1 _ 3 0 A 1 0 5 4 3 9 _ 1 0 d 1 0 5 7 1 3 _ 1 2 A 1 0 7 0 8 7 _ 2 0 D 1 0 6 8 0 1 _ 4 8 D 1 0 6 8 0 1 _ 1 6 D 1 0 6 5 2 6 _ 1 2 A 1 0 5 6 2 6 _ 1 2 B 1 0 6 5 2 6 _ 1 2 b 1 0 6 9 0 7 _ 2 8 A 1 0 6 9 0 7 _ 2 8 b 1 0 6 9 0 7 _ 2 8 c CRAMLINGTON KL BA MEXICO HOUSTON
Missing H information Missing L information Incorrect Information
c) Each parameter categorized as Y has been weighted as High and Low, depending on how much it is important, where H and L have got the following meaning.
• H (high) parameter:it is necessary for the analysis phase. A parameter is H for a phase
if the process cannot be carried out without it and you have to wait until the moment when the parameter is available. In this case the parameter is called Critical Parameter
• L (low) : A parameter is L for a phase when the parameter is not critical but useful for
the Analysis Interpretation or Analysts judgement eg. Age of Pipeline
The weighing of each parameter has been assigned by two Analyst Leader and two normal Analysts and the discordance between them has been handled in an open discussion.
After the point “a” the list contained 247 parameters. After the point “b” the parameters were 113 split up into 88 as H and 25 L. The outcome of this activity shows that the Analysts have to look at 247 parameters to find just the 88 information that they need.
The same procedure has been applied to the other technologies offered by PII. While for the main technologies the results are similar to the previous one, for the secondary technologies, like Calliper (CLP) or Cleaning (CLN) services, the discrepancy between the needed information and the available parameters is larger than the one shown above. This is because these minor technologies have got a few in common with the main technologies and they would need a lot of different information. On the other hand, it is necessary to consider that usually the request of
247 parameters a) b) 113 parameters c) 88 HIGH parameters 25 LOW parameters
forms filled in are the same. This means that a big part of the information that is not needed for CLP, for instance, is needed anyway, because of the other technology requested.
Now that all the needed information are known, it is clear that the first action to help the process of gathering the information may be to group them together and put them in the same location. This can help analysts giving the possibility to save time, finding all the needed information in the same place and, moreover, simplify the operation of control for missing information.
This action, on the other hand, implies to create an eDelivery Tab exclusively made up of automatically filled in fields and this can get some technical difficulties.
5.3 The Analysis Requirements Report
As introduced before, from the conversations between the candidate and Analysts and Commercial operations had emerged that a document with the same purpose already exists and it is called Analysis Requirements Report (ARR). The report is created by pressing the button Analysis from the eProject – Data Analysis – Data Analysis screen in eDelivery (as in Figure 32) and it is like in figure 33, 34 and 35.
Figure 11 Analysis Requirements Report page1
The first page contains the main information about what kind of service the client is asking for and its feature (see figure 33). The second page (shown in figure 34) contains a list of contacts where Analyst or PM can contact the client for any query. The third page is about the features of the pipeline. Any contract is split in section of different length in order to reduce the amount of data that the pig has to record. Any section can have different features and can be inspected with different tools, this is why the third page is characteristic for any of them. All the information contained within it come from the PQ.
Figure 13 Analysis Requirements Report page 3
From a brief comparison between this form and the CPL, it is easy to notice that it does not contain the right information and this is why Analyst do not use it for the aim it has been created for.
5.3.1 Some inaccuracies related with the System
The creation of the Report is tightly related with the how eDelivery works. In order to own a reliable ARR it is necessary to solve some inaccuracy of the system that are emerged during the meetings with the employee.
• Duplication of information – malfunction in the data input: Some parameters, shown in
the system more than one time in different points, are not automatically linked, and they have to be filled more than once. So the same parameters in PQ and AR have to be
inserted twice or, anyway, the operator has to check if the second location has been filled in by the system.
Figure 14 Example o duplication of information
Figure 36 also shows that in some cases, the duplication regards fields with different name like Year of Construction and Year Build. Even if in this case the difference is small, talking about technical parameters this inaccuracy is strictly forbidden.
• Missing Information – Some parameters are missing even if they are highlighted in red
to show their importance.
The colour red of some fields is the result of a previous project done in PII the previous year. The list of red parameters produced by this project has been analyzed and evaluated by the candidate with the help of responsible from ComOps, PM and Analysts. The outcome, already knows from the interview with them, has been that the list does not match the requirements of the Analysis phase and even less the requirements of the different technologies. Moreover, the parameters are red to highlight their importance but there is no procedure to count them or report the current situation for a contract. This is why the red parameters are completely ignored by the users.
• Lack of training – the system has not a clear ownership. This means that changes to it
have no need to be approved following a specific procedure. In this way, sometimes employee log into the system and find it different without any training or even notice. This situation is clearly to avoid and people must be trained on every change to the system to understand and utilize in the right way the changes.
• eDelivery is not user friendly – All these inaccuracies are causing annoyance on the people that have to deal with it every day, adding the frequent bugs and the slowness.
Another numerical evaluation of the phenomenon comes from the Customer Survey points. Using 253 of them, based on mobilizations dating from 2001 to 2006, 157 negative scores were recorded against Analysis deliverables. This problem represent a big issues to solve because the pipeline inspection market is becoming hard and competitive and a so negative point can produce a big damage to the company.
During this period approximately 7500 reports where issued under different mobilizations. The Customer Complaints system (2005-2006) highlighted 47 out of 130 complaints that were related to analysis deliverables.
Both sources point to four key areas of customer concern:
• Accuracy of results – Sizing/Location/Classification
• Content of Report – Use and value added information
• Software – Content and functionality
• Quarter end – Perception of quality reduction
The quarter is a period of 3 months and represent a financial term. Until the end of the quarter, PII has to reach defined standard and this is why much more work must be done causing a quality reduction.
Production monitoring has also shown approximately 1800 hours a quarter in client queries and re-issues, hours that represent a cost for the company.
A review of these systems of managing the information from the client could bring significant improvement related with the increases in customer satisfaction with zero reoccurrences of any errors.
Nevertheless:
• Reduction in the number of hours in rework and client queries
• Increase in operation effectiveness, by improving quality of the process and rigor
Once these elements are known, the candidate has asked herself which could be the more effective direction to move towards.
Some options have been considered and summarize in the graph below. Two have been the considered factors: the effort to implement the solution, results of a combination of time and costs and the impact that the action could have on solving the problem evaluated considering positive effects and reaction of the employee.
Taking into account time available and resources, the third option has been confirmed as the most effective.
The graph highlight how, reviewing the current system, it will be possible to achieve an high impact even if the implementation required some effort compared with the easier training activity. Following this direction, and in tune with the problem statement, the candidate has proposed to implement a metric system focused on the ARR after to have reviewed it.
The internal stakeholders of this kind of operation would be Analyst, Sales/Com Ops, Project managers, Clients and Marketing and the final customer would be all the external clients.
The investigation about the entity of the problem, carried out by the candidate, has produced the following results.
Looking at the eDelivery information recorded in case of problems, considering the inspection data of the last three months in Cramlington, where 58 inspections have taken place, the following has emerged:
N° %
Inspection data analyzed 58 100 Faulty Data 58 100 Defects coming from the field crew documentation 35 62 Defects coming from other function documentation 42 74
5.4 Reviewing the ARR
On time delivery is a primary customer requirement, a driver, and a key metric for GE – PII. On time delivery and accuracy in reporting is a very important point to ensure. In addition, analysis information and subsequent repair activity may have a huge impact ($$) on customer ‘s product
HIGH LOW
E
A
S
Y Training in order to
decrease the number of missing parameters
Leave the situation as is now
H
A
R
D Review of the present
system`s screen to tied the specific
request
Creation of a new system to manage the information from client to
analyst Im p le m e n ta ti o n Impact 1 2 3 4
deliveries. On time delivery of reports is crucial and a key beginning point for customer activities. Current on time delivery rates are 36% -100%, with only 3 of 7 technologies operating at the desired level (100%). Analysis will be able to schedule their people more effectively by knowing the report deliverables. Project management will not have to re-scope the analysis requirements with the customer losing time and money.
Currently, the required items on the Analysis Reporting form are only being completed from 64 to 78% of the times. For this reason, a review of the Analysis reporting forms and process is needed. Doing this, all required analysis reporting information will be available at the time of order.
The task of the candidate, at this sage, consists of matching perfectly the Analysis Requirements Report with the CPL. This is the first step in order to create a location where all the needed parameters are concentrated. Once this is done, it will be possible to create metrics or other measurement tools in order to improve and control the trend of missing information.
Taking ARR like only refer point to Analysts implies that it has to own several features:
Complete. ARR must contain all the critical information and no other information. This means that it should contain all the information considered critical for the Analysis (see Critical Parameters List) and that it has to be different for each technology, since their requirements are different.
Clear. ARR must contain fields with the right nomenclature, so that each field has its own univocal and clear meaning.
Trustworthy. ARR must contain the right value for each field. This means that the user does not need further checks on the value of the fields inside it.
Any of these points will be faced separately and some action will be suggested by the candidate to solve the problems.
5.4.1 Software Modification Requirement
As emerged from what is written above, the task will required modifications at the information management system. Any modification requested or made to it has to be approved following the established procedure.
The request of modification has to be submitted by the Support Central portal. In there, the user addresses his request specifying which areas of the software will be involved, which functions
will be involved, a brief description of the request and the priority of the modification. Finally, the SMR form has to be attached. It is structured in the following way:
MD050 SHORT PII Case# xxxxxx
Add the short title of the change here
Introduction
Give an introduction on what the software you are changing is for and why you are changing it.
Change Required
Give details of the changes you require. Be as specific as possible. Include screenshots
showing how the software looks now and indicate on the screenshots the changes you require.
Note
Give notes and specific examples to clarify your requirements.
Menu Routes
Show the menu route to the forms impacted by your change.
e.g. MST = eProjects -> Master Schedule Tracker -> Analysis Details
Test Cases
You MUST provide test cases or the document will be rejected. These cases show the developer how to test that the changes made have been successful.
Include specific examples relating to existing data in the system so the changes can be properly tested before handing back to you.
Technical Information
Summarise technical changes required for the enhancement. This section will be filled in by IM in most cases.
Add your name and the date here.
The request will be treated by an IT responsible and some email will inform the submitter about the advancement of the job.
Once the technical part has been finished, the IT department asks for the last authorization and after that the modifications are active.
5.4.2 Completeness
The completeness of the Report can be guaranteed matching the CPL with the ARR. This operation can be easy once the CPL has been built by the candidate for each technology,
although, communicating with sites far away to build CPL hasn’t been very easy and it has taken more than one month.
Any modification to the system requires to fill in the SMR as explained in the previous chapter. The result of the analytical review of the current situation against the CPLs has produced the following table (see table 3).
Table 2 Result of the completeness phase
As shown above for the MFL, just the 31% of the parameters are really needed for the Analysis, and the Analysts have to find them in the middle of 171 others parameters. The situation is almost the same for other technologies, where the average of needed parameters is around the 40% of the total.
The necessary SMRs have been filled in and the Proposal for the New Analysis Requirements Report has been presented during the weekly Data Control meeting.
5.4.3 Clearness
The new ARR comprehends a lot of parameters coming from several parts in eDelivery. For an Analyst, that has to use the report, is not necessary to know where the parameter comes from exactly, but the meaning of the field has to be clear and univocal, so that he can’t misunderstand the data inside it. Due to that, several fields have been modified, changing the current name with the name of the corresponding field in the original location and in some cases a little training about it has been done. Some example will show the inaccuracy founded and the necessity of clearness.
Figure 37 shows the screens respectively from the PQ and Analysis Requirements. The same field has different names, and this can generate errors.
Another action undertaken to reach clearness has been a repositioning and grouping of some fields and the changing of their name in a way that could produce a clearer and easier understanding of their mining.
5.4.4 Trustworthy
The aim of this action is to ensure that the Analyst does not need to double check the information that he finds in the report against the original source or asking to the PM. Moreover, if the parameter is missing, he has to be sure that it is not in any other part of the system. This task required the collaboration with the IT eDelivery responsible in Cramlington, John Elliot and with a member of the Business Systems team Malleswara Guptha Gotluru from India. Whit their collaboration it has been possible to deal with the technical problems raised to solve this duty. In order to verify the automatic update process between fields and to understand the links between them it would have been useful to create a graphical representation of the relationship (as shown in figure 38).
Figure 16 Graphical representation of the relationships Figure 15
As explained in the first chapter, eDelivery is a RDBMS in which data is stored in the form of tables and the relationship among the data is also stored in the form of tables. Thus, this graph would have come from the relational model where, in principle, any value occurring in two different records (belonging to the same table or to different tables), implies a relationship among those two records.
Building the system of relations between the fields would have been the first step towards the normalization of the DB. In relational database theory, normalization is the process of restructuring the logical data model of a database to eliminate redundancy, organize data efficiently, reduce repeating data and to reduce the potential for anomalies during data operations. Data normalization also may improve data consistency and simplify future extensions of the logical data model.
A non-normalized database can suffer from data anomalies:
• A non-normalized database may have inappropriate dependencies, i.e. relationships between data with no functional dependencies. Adding data to such a database may require first adding the unrelated dependency. A normalized database prevents such insertion anomalies by ensuring that database relations mirror functional dependencies.
• A non-normalized database may store data representing a particular referent in multiple
locations. An update to such data in some but not all of those locations results in an update anomaly, yielding inconsistent data. A normalized database prevents such an anomaly by storing such data (i.e. data other than primary keys) in only one location.
• Similarly, such dependencies in non-normalized databases can hinder deletion. That is,
deleting data from such databases may require deleting data from the inappropriate dependency. A normalized database prevents such deletion anomalies by ensuring that all records are uniquely identifiable and contain no extraneous information
Normalized databases have a design that reflects the true dependencies between tracked quantities, allowing quick updates to data with little risk of introducing inconsistencies. Instead of attempting to lump all information into one table, data is spread out logically into many tables. Normalizing the data is decomposing a single relation into a set of smaller relations which satisfies the constraints of the original relation. Redundancy can be solved by decomposing the tables. However certain new problems are caused by decomposition. Normalization helps us to make a conscious decision to avoid redundancy keeping the pros and cons in mind.
The transformation of conceptual model to computer representation format is known as Normalization.
COs PM DC An COs PM DC An
1 Re-Inspection/Comparsion
eSales- Customer Requirements - PQ/Sections/Services
Project - Data Analysis/Data Analysis (Previously Inspected by PII)
eSales - Customer Requirements - Analysis
Requirements/MFL/TFI/HR report contents (Previously Inspected by PII)
eSales - Customer Requirements - Analysis
Requirements Form X X X X
Change the name in Scn 1 with Re-Inspection/Comparison
2 Preliminary Report Days
eProject - Data Analysis/Data Analysis (Timescale Cal. Days)
eSales - Customer Requirements - Analysis Requirements/MFL/TFI/HR report contents
eSales - Customer Requirements -
Analysis Requirements Form X X X X
3 Final report Days
eProject - Data Analysis/Data Analysis (Timescale Cal. Days)
eSales - Customer Requirements - Analysis Requirements/MFL/TFI/HR report contents
eSales - Customer Requirements -
Analysis Requirements Form X X X X
4 Nom. MAOP X X X
5 Nom. Design. P X X X
6 Steel Grade X X X
7 Year of Costruction
eSales- Customer Requirements - PQ/Sections/SubSection
eSales - Customer Requirements - Analysis Requirements/MFL/TFI/HR Pipeline Code Require (Year Build)
eSales - Customer Requirements - Analysis Requirements Form (Year
Build) X X X
8 Product X X X
9 Gas/Liq/2/3 Phase X X X
10 Comments X X X
11 Specification
eSales- Customer Requirements - PQ/Sections/Services
eSales - Customer Requirements - Analysis Requirements/MFL/TFI/HR Cluste/Feature Rules (Feature Selection Rule)
eSales - Customer Requirements - Analysis Requirements Form (Feature Selection Rule)
eProject - Resources - System Settings/ Critical Inputs
(Reporting Specification) X X X
13 Diameter
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/SubSection X X X
14 Phase Type
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/Product X X X
15 Wall T
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/SubSection X X X
16 Length
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/SubSection X X X
17 Flow Rate
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/Product X X X
18 Pressure
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/Product X X X
19 Temperature
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/Product X X X
20 Pipe Type
eProject - Resources - System Settings/ Critical Inputs
eSales- Customer Requirements -
PQ/Sections/SubSection X X X
21 Run Time Model
eProject - Resources - System
Settings/ Critical Inputs ? X X X
eSales- Customer Requirements - PQ/Sections/Product
eSales - Customer Requirements - Analysis Requirements Form
Screen 4
Item Screen 1 Screen 2 Screen 3 Notes
eSales- Customer Requirements - PQ/Sections/SubSection
eSales - Customer Requirements - Analysis Requirements/MFL/TFI/HR Pipeline Code Require
eSales - Customer Requirements - Analysis Requirements Form
Access Right Visibility
Unfortunately, this level of detail, to verify the automatic update process between fields, could not be supplied by the Business Systems team, and the only possible operation about normalization has been to produce a list of fields involved in the ARR with their correspondent fields in the other positions (see table 4) so that IT could verify the link between them.
Considering the reflections above, 76 requests of software’s modification have been created and submitted (see table 5).
Table 5 List of submitted SMR
The result of all the tasks explained above has been carried into effect producing the relative SMRs and submitting them following the procedure in chapter 5.4.1.
Figure 17 The new ARR
The final proposal for the new ARRs has been shown in the meeting with the DC team and one of them is illustrated in figure 38.
5.5 Review of the timing
After the new information have been collected, the timing has been reviewed with the following outcome:
Aspect of the task Due date
Analysing the task 17th October ‘06
Acknowledgment (clarify the context) • Analysis Process
• Process of Collection of the parameters
5th January ‘07
Outline options 1st February ‘07
Work out the right solution 15th February ‘07
Implement the solution chosen 30th March ‘07
The lack of documentation about some arguments needed deep investigations by the candidate and these operations asked a lot of time. This is why the second task has been longer than expected and the third task has been postponed of at least 2 weeks.
