User Tools
en:handbuch:kapitel_a:glossar
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
en:handbuch:kapitel_a:glossar [2009/11/04 16:28] 192.168.0.76 |
en:handbuch:kapitel_a:glossar [2019/10/25 14:11] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | [[handbuch:kapitel_4:4.12.4_fakturaauswertungen|{{|zurück}}]] [[handbuch:handbuch|{{|Home}}]] [[handbuch:kapitel_b:kontakt|{{|weiter}}]] | + | [[en:handbuch:kapitel_4:4.12.4_fakturaauswertungen|{{|previous}}]] [[en:handbuch:handbuch|{{|Home}}]] [[en:handbuch:kapitel_b:kontakt|{{|next}}]] |
| ====== Glossary ====== | ====== Glossary ====== | ||
| Line 14: | Line 14: | ||
| - | ===== Approval(Freigabe)===== | + | ===== Approval ===== |
| Approval refers to, depending on the context, approving a plan, sharing something for certain purposes or granting certain rights to a person. In project management, approval is described as the authorization to carry out subsequent work with defined contents. An approval is often associated with quality control and is usually defined as a milestone in the project plan. | Approval refers to, depending on the context, approving a plan, sharing something for certain purposes or granting certain rights to a person. In project management, approval is described as the authorization to carry out subsequent work with defined contents. An approval is often associated with quality control and is usually defined as a milestone in the project plan. | ||
| Line 26: | Line 26: | ||
| ===== Bar Chart-Network Diagram (=Networked Bar Diagram, Network-Gantt) ===== | ===== Bar Chart-Network Diagram (=Networked Bar Diagram, Network-Gantt) ===== | ||
| - | A bar chart-network diagram is an extension of the [[#bar chart|bar chart]] to display the dependencies between [[#job|jobs]] or [[#Project|projects]]. In Projectile cross-linked processes in the document [[en:handbuch:kapitel_2:2.02.07_anordnungsbeziehung|project timing/order relationship]] are defined and visualized in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project chart]]. | + | A bar chart-network diagram is an extension of the [[#Bar Chart|bar chart]] to display the dependencies between [[#job|jobs]] or [[#Project|projects]]. In Projectile cross-linked processes in the document [[en:handbuch:kapitel_2:2.02.07_anordnungsbeziehung|project timing/order relationship]] are defined and visualized in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|Gantt chart]]. |
| {{:handbuch:glossar:balken-netzplan.jpg?direct}} | {{:handbuch:glossar:balken-netzplan.jpg?direct}} | ||
| Line 33: | Line 33: | ||
| ===== Bar Chart (= Gantt-Diagram) ===== | ===== Bar Chart (= Gantt-Diagram) ===== | ||
| - | A bar chart is a diagram for visualizing the time planning of a [[#Projekt|project]]. The duration of a [[#Job|job]] or project are symbolized through the length of the bar in the time axis. The bars contain either actual data or target data. Events or [[#Milestone|milestones]] are displayed as time points. In Projectile the processes are visualized in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project charts]]. | + | A bar chart is a diagram for visualizing the time planning of a [[#Project|project]]. The duration of a [[#Job|job]] or project are symbolized through the length of the bar in the time axis. The bars contain either actual data or target data. Events or [[#Milestone|milestones]] are displayed as time points. In Projectile the processes are visualized in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project charts]]. |
| - | {{:handbuch:glossar:netzplan.jpg?direct}} | + | {{:en:handbuch:kapitel_a:gantt_diagram1.jpg|}} |
| Line 58: | Line 58: | ||
| ===== Buffer Time ===== | ===== Buffer Time ===== | ||
| - | The buffer time is a term used in network diagram technology. The buffer time is a temporal scope for performing a process. This margin can be applied by shifting the process and/or by extending the task duration. From the information of various specifications in the network diagram, four types of buffer time can be determined. Most often used are the total float and the free buffers. | + | The buffer time is a term used in network diagram technology. The buffer time is a temporal scope for performing a process. This margin can be applied by shifting the process and/or by extending the task duration. From information of various specifications, four types of buffer time can be determined in the network diagram. Most often used are the total float and the free buffers. |
| - | The total float of a task i is calculated as the difference of LSi (late start date of i) and ESi (Early start date of i) or LFi (Late finish date of i) and EFi (Early finish date of i). The total float indicates how much the process can be shifted without jeopardizing the project end: Total float = LSi - | + | The total float of a task i is calculated as the difference of LSi (late start date of i) and ESi (Early start date of i) or LFi (Late finish date of i) and EFi (Early finish date of i). The total float indicates how much the process can be shifted without jeopardizing the project end: Total float = LSi - ESi = LFi - EFi . |
| - | ESi = LFi - EFi . | + | |
| The free buffer is the time, which does not endanger the earliest possible begin and/or end of the successor. (Formally: All successor processes can be performed at its earliest time). It can only occur if at least two completed operations have the same successor. The calculation occurs with a "normal sequence" (end - start) by forming the difference of early end of the considered process and the early start of its successor. With a begin sequence (start - start) the earliest start dates are compared and with an end sequence (end - end), the earliest end dates of the transactions are compared. | The free buffer is the time, which does not endanger the earliest possible begin and/or end of the successor. (Formally: All successor processes can be performed at its earliest time). It can only occur if at least two completed operations have the same successor. The calculation occurs with a "normal sequence" (end - start) by forming the difference of early end of the considered process and the early start of its successor. With a begin sequence (start - start) the earliest start dates are compared and with an end sequence (end - end), the earliest end dates of the transactions are compared. | ||
| - | |||
| - | Die Pufferzeit ist ein Begriff aus der Netzplantechnik. Die Pufferzeit ist ein zeitlicher Spielraum für die Ausführung eines Vorganges. Dieser Spielraum kann durch Verschiebung des Vorganges und/oder durch Verlängerung (Dehnung) der Vorgangsdauer genutzt werden. Aus den Angaben mehrerer Vorgaben lassen sich im Netzplan anschließend vier Arten von Pufferzeit bestimmen. Am häufigsten werden der Gesamtpuffer und der Freie Puffer verwendet. | ||
| - | Der Gesamtpuffer GPi eines Vorgangs i errechnet sich aus der Differenz von SAZi (Spätester Anfangszeitpunkt von i) und FAZi (Frühester Anfangszeitpunkt von i), bzw. SEZi (Spätester Endzeitpunkt von i) und FEZi (Frühester Endzeitpunkt von i). Das heißt, der Gesamtpuffer gibt an um wie viel sich der Vorgang verschieben lässt ohne das Projektende zu gefährden: GPi = SAZi − FAZi = SEZi − FEZi. | ||
| - | Der Freie Puffer ist die Zeit, die den frühest möglichen Beginn bzw. Ende des Nachfolgers nicht gefährdet. (Formal: Alle Nachfolge-Vorgänge können in ihrer frühesten Lage durchgeführt werden). Er kann nur entstehen, wenn mindestens zwei abgeschlossene Vorgänge auf denselben Nachfolger treffen. Seine Berechnung erfolgt bei einer "Normalfolge" (Ende - Anfang) durch Bildung der Differenz von Frühestem Ende des betrachteten Vorgangs und dem Frühestem Beginn seines Nachfolgers. Bei einer Anfangsfolge (Anfang - Anfang) werden die frühesten Anfangstermine und bei einer Endfolge (Ende - Ende) die frühesten Endetermine der Vorgänge verglichen. | ||
| - | |||
| ===== Calculation ===== | ===== Calculation ===== | ||
| Line 79: | Line 73: | ||
| ===== Capacity Requirement (= Resource Requirement) ===== | ===== Capacity Requirement (= Resource Requirement) ===== | ||
| - | Capacity requirement or resource requirement refers to the demand of staff and resources required for processing of the [[[#Job| jobs]] of a [[#Project|project]] necessary to determine the estimated costs and the time span of the network diagram. | + | Capacity requirement or resource requirement refers to the demand of staff and resources required for processing of the [[#Job| jobs]] of a [[#Project|project]] necessary to determine the estimated costs and the time span of the network diagram. |
| Line 87: | Line 81: | ||
| - | ===== Contractor/Agent (Auftragnehmer) ===== | + | ===== Contractor/Agent ===== |
| The contractor/agent is the salesperson of a product or a service. He/she is the contract partner of the [[#Customer|customer]], who buys the services agreed upon in the order. | The contractor/agent is the salesperson of a product or a service. He/she is the contract partner of the [[#Customer|customer]], who buys the services agreed upon in the order. | ||
| Line 115: | Line 109: | ||
| - | ===== Customer (Auftraggeber) ===== | + | ===== Customer ===== |
| The customer is completely responsible for the [[#Project|project]]. The customer approves the project budget and the [[#Scheduling|scheduling]]. In Projectile the customer is administered in the document type [[en:handbuch:kapitel_2:2.01.13_basic_-_kontakt|customer]]. The person responsible for the project has the role of the contractor towards the customer of the project. In project management, the contract management and purchasing management deals with the relationship between the customer role and contractor role. | The customer is completely responsible for the [[#Project|project]]. The customer approves the project budget and the [[#Scheduling|scheduling]]. In Projectile the customer is administered in the document type [[en:handbuch:kapitel_2:2.01.13_basic_-_kontakt|customer]]. The person responsible for the project has the role of the contractor towards the customer of the project. In project management, the contract management and purchasing management deals with the relationship between the customer role and contractor role. | ||
| Line 135: | Line 129: | ||
| ===== Invoicing (=Cost Sheet) ===== | ===== Invoicing (=Cost Sheet) ===== | ||
| - | With invoicing, goods or service from the supplier are paid for by the purchaser by agreement. The compensation can be performed on the basis of time/effort or fixed-price and is usually controlled through payment plans. With time/effort-related compensation, the customer often demands a detailed list of all resulting expenses or costs on the invoice. DIN 69903 interprets invoicing as a complete process from costing to the assignment and billing to recognition of the invoice. In Projectile this functionality is illustrated through the [[en:handbuch:kapitel_2:2.04_fakturamodul_optional | Billing Module]]. | + | With invoicing, goods or service from the supplier are paid for by the purchaser by agreement. The compensation can be performed on the basis of time/effort or fixed-price and is usually controlled through payment plans. With time/effort-related compensation, the customer often demands a detailed list of all resulting expenses or costs with the invoice. DIN 69903 interprets invoicing as a complete process from costing, assignment and billing to acceptance of the invoice. In Projectile this functionality is illustrated through the [[en:handbuch:kapitel_2:2.04_fakturamodul_optional | Billing Module]]. |
| - | + | ||
| - | + | ||
| - | Bei einer Rechnungsstellung werden Waren oder Dienstleistungen des Anbieters vom Abnehmer nach Vereinbarung vergütet. Die Vergütung kann auf Basis von Aufwänden oder Festpreisen durchgeführt werden und wird in der Regel durch Zahlungspläne gesteuert. | + | |
| - | Bei einer aufwandsbezogenen Vergütung verlangt der Auftraggeber mit der Rechnungsstellung oft eine detaillierte Aufstellung aller entstandenen Aufwände bzw. Kosten. Die DIN 69903 interpretiert die Rechnungsstellung als gesamten Prozess von der Kostenerfassung über die Zuordnung und Rechnungsstellung bis hin zur Anerkennung der Rechnung aus. In Projectile wird diese Funktionalität durch das [[handbuch:kapitel_2:2.04_fakturamodul_optional|Fakturamodul]] abgebildet. | + | |
| ===== Job ===== | ===== Job ===== | ||
| Line 159: | Line 148: | ||
| A milestone is a significant control event in the [[#project plan|project plan]], defined by a deadline and results that must be available at this date to the agreed quality according to the project order. Typical milestones are typically critical interim results, approvals, production start, etc. In Projectile the milestones are defined in the document type [[en:handbuch:kapitel_2:2.02.05_meilenstein|milestone]] and the trend dates for the [[#milestone-trend-analysis|milestone trend analysis]] are administered in the document type [[en:handbuch:kapitel_2:2.02.06_trendtermin|deadline]]. | A milestone is a significant control event in the [[#project plan|project plan]], defined by a deadline and results that must be available at this date to the agreed quality according to the project order. Typical milestones are typically critical interim results, approvals, production start, etc. In Projectile the milestones are defined in the document type [[en:handbuch:kapitel_2:2.02.05_meilenstein|milestone]] and the trend dates for the [[#milestone-trend-analysis|milestone trend analysis]] are administered in the document type [[en:handbuch:kapitel_2:2.02.06_trendtermin|deadline]]. | ||
| - | |||
| Line 166: | Line 154: | ||
| The milestone-trend-analysis is a future-related tool for controlling the schedule of a [[#Project|project]]: On periodical reporting dates the [[#Schedule|schedule]] of the project is re-estimated through retrieving trend data of the estimated milestone achievement. From the curve progression, a trend can be inferred through the adherence of deadlines of the project. The deadlines for the milestones can be administered in the document type [[en:handbuch:kapitel_2:2.02.06_trendtermin|deadlines]] and the analysis is visualized in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project chart]]. | The milestone-trend-analysis is a future-related tool for controlling the schedule of a [[#Project|project]]: On periodical reporting dates the [[#Schedule|schedule]] of the project is re-estimated through retrieving trend data of the estimated milestone achievement. From the curve progression, a trend can be inferred through the adherence of deadlines of the project. The deadlines for the milestones can be administered in the document type [[en:handbuch:kapitel_2:2.02.06_trendtermin|deadlines]] and the analysis is visualized in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project chart]]. | ||
| - | {{:handbuch:glossar:mta.gif?direct}} | + | {{:en:handbuch:kapitel_a:mta1_sm.jpg|}} |
| ===== Multi-Project Management (=Program Management) ===== | ===== Multi-Project Management (=Program Management) ===== | ||
| Line 190: | Line 177: | ||
| An organizational unit is an element of the organizational structure, which is generally visualized in an organigram. Examples of organizational units are subsidiaries, branches, divisions or departments. In Projectile organizational units are illustrated using the form [[en:handbuch:kapitel_2:2.01.27_basic_-_unit | unit]]. | An organizational unit is an element of the organizational structure, which is generally visualized in an organigram. Examples of organizational units are subsidiaries, branches, divisions or departments. In Projectile organizational units are illustrated using the form [[en:handbuch:kapitel_2:2.01.27_basic_-_unit | unit]]. | ||
| + | |||
| ===== Payment Plan ===== | ===== Payment Plan ===== | ||
| Line 209: | Line 197: | ||
| Portfolio management refers to the administration of a portfolio, i.e. a stock of investments. The portfolio management process includes the portfolio planning (selection and analysis), the realization of portfolio (monitoring and auditing), and portfolio control (performance measurement, attribution). In relation to projects questions about the alignment of project objectives with company strategy, project evaluation and the earnings prospects of projects have priority. The methods included to the portfolio management are composition, structure and key figures determination of portfolios, assessment and prioritization of investments and the simulation of possible portfolios. | Portfolio management refers to the administration of a portfolio, i.e. a stock of investments. The portfolio management process includes the portfolio planning (selection and analysis), the realization of portfolio (monitoring and auditing), and portfolio control (performance measurement, attribution). In relation to projects questions about the alignment of project objectives with company strategy, project evaluation and the earnings prospects of projects have priority. The methods included to the portfolio management are composition, structure and key figures determination of portfolios, assessment and prioritization of investments and the simulation of possible portfolios. | ||
| + | |||
| + | |||
| + | =====Predecessor ===== | ||
| + | |||
| + | The predecessor is an integral part of the [[en:handbuch:kapitel_2: 2.02.07_anordnungsbeziehung | order relationship]] and describes the relationships between processes within a process chain. Due to the logic of processing steps to manufacture a product or a service, certain processes may only be performed after one or more other processes are completed. Within the network diagram technique in the context of project planning, the predecessor is process in which a process precedes another process. | ||
| Line 222: | Line 215: | ||
| - If nothing is stored here either, the system checks whether [[#project-related occupations|project-related occupations]] are defined for this project. If there are no definitions, it will be determined whether [[#customer-related occupations|customer-related occupations]] are stored with the customer of the project and what rates are available. | - If nothing is stored here either, the system checks whether [[#project-related occupations|project-related occupations]] are defined for this project. If there are no definitions, it will be determined whether [[#customer-related occupations|customer-related occupations]] are stored with the customer of the project and what rates are available. | ||
| - If no cost rate exists here either, the general external occupation rate of the firm (see [[#Occupation|occupations]]) is used for cost transfers. | - If no cost rate exists here either, the general external occupation rate of the firm (see [[#Occupation|occupations]]) is used for cost transfers. | ||
| + | |||
| + | |||
| + | ===== Process ===== | ||
| + | |||
| + | The jobs which are defined in the work breakdown structure, are (in terms of network diagram technology) processes. The processes are then linked through order relationships with one another. Processes are depending on the network diagram type, symbolized through arrows or through nodes. Processes are created through the project planning from the jobs. | ||
| Line 313: | Line 311: | ||
| * End sequence (End - End) | * End sequence (End - End) | ||
| * Jump sequence (Begin - End) | * Jump sequence (Begin - End) | ||
| - | |||
| Line 325: | Line 322: | ||
| It must be accessible, complete, consistent, auditable, documented and jointly agreed upon between the [[#Customer| customer]] and [[# Project manager | project management]]. | It must be accessible, complete, consistent, auditable, documented and jointly agreed upon between the [[#Customer| customer]] and [[# Project manager | project management]]. | ||
| - | |||
| - | =====Predecessor ===== | ||
| - | |||
| - | The predecessor is an integral part of the [[en:handbuch:kapitel_2: 2.02.07_anordnungsbeziehung | order relationship]] and describes the relationships between processes within a process chain. Due to the logic of processing steps to manufacture a product or a service, certain processes may only be performed after one or more other processes are completed. Within the network diagram technique in the context of project planning, the predecessor is process in which a process precedes another process. | ||
| - | |||
| - | ===== Process ===== | ||
| - | |||
| - | The jobs which are defined in the work breakdown structure, are (in terms of network diagram technology) processes. The processes are then linked through order relationships with one another. Processes are depending on the network diagram type, symbolized through arrows or through nodes. Processes are created through the project planning from the jobs. | ||
| Line 344: | Line 333: | ||
| The scheduling of personnel, equipment and other tools needed for the project work is the task of resource management. The aim of resource management is the optimal utilization of resources and the best suitable provision for the projects using these tools. The working times for working resources must be minimized, since they burden the project budget with appropriate costs. From the perspective of the organization is is strived for the most possible uniform and high utilization of resources. | The scheduling of personnel, equipment and other tools needed for the project work is the task of resource management. The aim of resource management is the optimal utilization of resources and the best suitable provision for the projects using these tools. The working times for working resources must be minimized, since they burden the project budget with appropriate costs. From the perspective of the organization is is strived for the most possible uniform and high utilization of resources. | ||
| + | ===== Scheduling ===== | ||
| + | |||
| + | Scheduling includes planning the start and finish times of all the [[#Job|jobs]] of a [[#Project | project]]. | ||
| ===== Sequence Planning ===== | ===== Sequence Planning ===== | ||
| Line 351: | Line 343: | ||
| ===== SPI ===== | ===== SPI ===== | ||
| - | The SPI (Schedule Performance Index) is the time-related performance key figure of the earned value analysis. It is formed from the ratio of earned value and estimated effort. This means that with a SPI of greater than 1.00 (100%) the project results are delivered faster than originally planned, and with a value of less than 1.00 (100%), the project is progressing too slowly. | + | The SPI (Schedule Performance Index) is the time-related performance key figure of the earned value analysis. It is formed from the ratio of earned value and estimated effort. This means that with an SPI of greater than 1.00 (100%) the project results are delivered faster than originally planned, and with a value of less than 1.00 (100%), the project is progressing too slowly. |
| + | |||
| + | ===== Sub-Project ===== | ||
| + | |||
| + | Larger projects are usually divided into sub-projects according to certain criteria (functional, organizational, technical, etc.) to manage and administer them better. With temporal division/splitting, sub-projects are often called project phases. | ||
| ===== Successor ===== | ===== Successor ===== | ||
| Line 366: | Line 363: | ||
| Time/effort estimation is the estimation of the necessary time or effort for processing a [[#Arbeitspaket|job]]. This is based on the experience of the [[#Projektmitarbeiter|project employee]] and is the foundation of [[#Kapazitätsplanung|capacity planning]] and [[#Terminplanung|deadline planning]]. In Projectile the target times (the time/effort) can be estimated on the project level and job level. | Time/effort estimation is the estimation of the necessary time or effort for processing a [[#Arbeitspaket|job]]. This is based on the experience of the [[#Projektmitarbeiter|project employee]] and is the foundation of [[#Kapazitätsplanung|capacity planning]] and [[#Terminplanung|deadline planning]]. In Projectile the target times (the time/effort) can be estimated on the project level and job level. | ||
| - | |||
| - | |||
| - | ===== Sub-Project ===== | ||
| - | |||
| - | Larger projects are usually divided into sub-projects according to certain criteria (functional, organizational, technical, etc.) to manage and administer them better. With temporal division/splitting, sub-projects are often called project phases. | ||
| - | |||
| - | |||
| - | ===== Scheduling ===== | ||
| - | |||
| - | Scheduling includes planning the start and finish times of all the [[#Job|jobs]] of a [[#Project | project]]. | ||
| ===== Top Down-Planning ===== | ===== Top Down-Planning ===== | ||
| Line 387: | Line 374: | ||
| - | ===== Work Breakdown Structure ===== | + | ===== Work Breakdown Structure ===== |
| + | |||
| + | A work breakdown structure (project structure plan) is the subdivision of a project in work-related parts, e.g. phases, work orders, work procedures. | ||
| - | A work breakdown structure (WBS) is the subdivision of a project in work-related parts, e.g. phases, work orders, work procedures. | + | {{:en:handbuch:kapitel_a:strukture_plan1.gif|}} |
| - | {{:handbuch:glossar:struktur_plan.gif?direct}} | ||
| In Projectile the work breakdown structures are generated in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project chart]]. | In Projectile the work breakdown structures are generated in the [[en:handbuch:kapitel_2:2.5.09_projektauswertung|project chart]]. | ||
en/handbuch/kapitel_a/glossar.1257348508.txt.gz · Last modified: 2019/10/25 14:09 (external edit)
