Difference between revisions of "Effort Engineering Quarter"

From CNM Wiki
Jump to: navigation, search
(Methods)
 
(169 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Process Engineering Quarter]] (hereinafter, the ''Quarter'') is the first of four lectures of [[Effort Quadrivium]] (hereinafter, the ''Quadrivium''):
+
[[Effort Engineering Quarter]] (hereinafter, the ''Quarter'') is a lecture introducing the learners to [[operations design]] primarily through key topics related to [[effort engineering]]. The ''Quarter'' is the third of four lectures of [[Operations Quadrivium]], which is the third of seven modules of '''[[Septem Artes Administrativi]]''' (hereinafter, the ''Course''). The ''Course'' is designed to introduce the learners to general concepts in [[business administration]], [[management]], and [[organizational behavior]].
*The ''Quarter'' is designed to introduce its learners to [[enterprise discovery]], or, in other words, to concepts related to obtaining data needed to administer the [[enterprise effort]]; and
 
*The ''Quadrivium'' examines concepts of administering various types of enterprises known as [[enterprise administration]] as a whole.
 
 
 
The ''Quadrivium'' is the first of seven modules of [[Septem Artes Administrativi]], which is a course designed to introduce its learners to general concepts in [[business administration]], [[management]], and [[organizational behavior]].
 
  
  
 
==Outline==
 
==Outline==
''The predecessor lecture is [[Controlling Quarter]].''
+
''[[Controlling Quarter]] is the predecessor lecture.  In the [[enterprise envisioning]] series, the previous lecture is [[Business Modeling Quarter]].''
  
 
===Concepts===
 
===Concepts===
#'''[[Production]]'''.
+
#'''[[Effort engineering]]'''. The creative application of science, mathematical methods, and empirical evidence to the innovation, design, construction, operation and maintenance of [[process]]es.
 +
#*[[Enterprise effort]]. A determined attempt or a set of attempts undertaken in order to obtain outcomes of a [[job task]], [[activity]], [[process]], [[project]] or [[operations]], and/or [[enterprise]].
 +
#*[[Effort administration]]. The intersection of [[product ownership]] and [[project management]].
 +
#*[[Optimization]]. The [[process]] of choosing the best alternative that will satisfy the needs of the stakeholders under the constraints given (e.g. cost, schedule and available technology).
 +
#*[[Bottleneck]]. A machine or workstation through which many production items must flow and which when overloaded causes a delay in the [[production process]].
 +
#[[File:Process.png|400px|thumb|right|[[Process]]]]'''[[Process]]'''. A sequenced series, predefined, empiric, and/or merely chaotic, of [[activity|activiti]]es undertaken in order to achieve particular results. In other words, a [[process]] is a repetitive or ad-hoc way of work. [[Effort engineering]] defines that those ''activities'' convert [[input]]s into desired [[output]]s utilizing some [[process asset]]s such as tools and [[technique]]s and while being influenced by some [[enterprise factor]]s. Non-repetitive [[process]]es are called [[management process]]es. Repetitive [[process]]es that are performed by people for [[enterprise]]s are called [[business process]]es; those of their sets that produce a [[deliverable]] are called [[operations]]. Repetitive [[process]]es that are performed by [[system]]s including computers, robots, and/or machines are called [[system process]]es.
 +
#*[[Input]]. Anything consumed in a [[process]]. In [[systems engineering]], items that are processed by the [[system]].
 +
#*[[Process asset]]. All materials used by groups within an organization to define, tailor, implement, and maintain their [[process]]es.
 +
#*[[Enterprise factor]]. A circumstance, fact, or influence that contributes to any [[output]] from an [[enterprise effort]].
 +
#*[[Technique]]. A way of carrying out a particular task, especially the creation, execution, and/or performance of an [[enterprise effort]], artistic work, or a scientific procedure.
 +
#'''[[Output]]'''. Anything that directly emerges out of a [[process]]. In [[systems engineering]], items that the [[system]] produces.
 +
#*[[Deliverable]]. Anything that one party has agreed to deliver to another party. A [[deliverable]] is a tangible and/or intangible [[output]] that is produced by a [[project]] or [[operations]] and ready to be shipped to the beneficiaries. Usually, a [[deliverable]] consists of an [[unpackaged deliverable]] and [[packaging]].
 +
#*[[Feedback]]. (1) [[Data]] that is an [[output]] from one [[system]] delivered back to one of the systems that feed the system that produces the data; (2) [[Information]] based on [[data]] that is an [[output]] from one [[system]] delivered back to one of this system's suppliers; (3) The degree to which carrying out the work activities required by a job results in the individual's obtaining direct and clear information about the effectiveness of his or her performance.
 +
#'''[[Outcome]]'''. A key factor that is affected by some other variables.
 +
#*[[Desired outcome]]. The business benefits that will result from meeting the business need and the end state desired by stakeholders.
 +
#'''[[Process property]]'''. An attribute, [[quality]], or characteristic of a [[process]].
 +
#*[[Process boundary]]. (1) Clearly defined beginning or the end of a [[process]]; (2) A separation between what happens inside of a [[process]] and what happens outside.
 +
#*[[Workflow]]. A sequential flow of work; it must consist of activities that are ordered according to their position in time and space (a sequence).
 +
#*[[Output beneficiary]]. There must be a recipient of the process' outcome, a customer.
 +
#*[[Added value]]. The transformation taking place within the process must add value to the recipient, either upstream or downstream.
 +
#*[[Embeddedness]]. A process cannot exist in itself, it must be embedded in an organizational structure.
 +
#*[[Process functionality]]. A process regularly can, but not necessarily must, span several functions.
 +
#*[[Process trigger]]. Something that activates a [[process]].
 +
#*[[Process ownership]]. An [[authority]] to make decisions to change the [[process]].
 +
#*[[Control logic]]. A [[system]] or set of principles underlying the [[process owner]]'s ability to control the [[process]].
 +
#'''[[Business process]]'''. A set of defined collaborative activities performed in a repeatable fashion by an [[enterprise]]. Processes are triggered by events and may have multiple possible outcomes. A successful outcome of a process is going to deliver value to one or more [[stakeholder]]s.
 +
#*[[Production process]].
 +
#*[[Cycle]]. Refers to the total amount of time it takes for a single task or work item to travel through the workflow from the beginning of work until it ships.
 +
#'''[[Production]]'''. The action of making or manufacturing from components or raw materials, or the [[process]] of being so manufactured.
 
#*[[Process production]]. The production of items in continuous process.
 
#*[[Process production]]. The production of items in continuous process.
*[[Operational plan]]. A [[plan]] that encompasses a particular operational area of the organization.
+
#*[[Unit production]]. The production of items in units or small batches.
 
 
#*[[Operations]] (or [[Operations|Ongoing operations]]). Repetitive [[enterprise effort]]s undertaken in order to create a specified [[deliverable]] or a batch of specified [[deliverable]]s using already designed process.
 
 
 
 
 
#'''[[Process]]'''. An action that individuals, groups, and organizations engage in as a result of [[input]]s and that leads to certain [[output]]s.
 
#*[[Process]]. A set of activities used to convert inputs into desired outputs.
 
#*[[Process]]. simply the way someone works. Everyone has a process. It can be pre-defined, empiric or merely chaotic.
 
#*[[Business process]]. A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization. Processes are triggered by events and may have multiple possible outcomes. A successful outcome of a process will deliver value to one or more stakeholders.
 
#*[[Input]]. A variable that leads to [[process]]es.
 
#*#[[Input]]. A material, service or support item that is processed by the system.
 
#*[[Output]]. An immediate and direct result of a [[process]].
 
#*[[Organizational process asset]]. All materials used by groups within an organization to define, tailor, implement, and maintain their processes.
 
#*[[Technique]]. Techniques alter the way a business analysis task is performed or describe a specific form the output of a task may take.
 
#*[[Cycle]]. refers to the total amount of time it takes for a single task or work item to travel through the workflow from the beginning of work until it ships.
 
 
#*[[Production environment]]. A term describing the setting where a product is put into use by customers on a regular basis.
 
#*[[Production environment]]. A term describing the setting where a product is put into use by customers on a regular basis.
#'''[[Activity]]'''. A unit of work performed as part of an initiative or process.
+
#*[[Operational support]]. A stakeholder who helps to keep the solution functioning, either by providing support to end users (trainers, help desk) or by keeping the solution operational on a day-to-day basis (network and other tech support).
#*[[Activity]]. The smallest portion of an [[enterprise effort]] that has its own name, input, description, timeframe, and measurable result.
+
#'''[[Activity]]'''. Any [[enterprise effort]] performed as part of a [[process]]. An [[activity]] shall have its own name and description; most often, they have one or more [[predecessor activity|predecessor activiti]]es and [[successor activity|successor activiti]]es. Planned activities may have their expected input resources, process assets, time frames, and costs; completed activities may have their actual data. [[Activity|Activiti]]es may be subdivided into [[job task]]s.
 
#*[[Activity diagram]]. A model that illustrates the flow of processes and/or complex use cases by showing each activity along with information flows and concurrent activities. Steps can be superimposed onto horizontal swimlanes for the roles that perform the steps.
 
#*[[Activity diagram]]. A model that illustrates the flow of processes and/or complex use cases by showing each activity along with information flows and concurrent activities. Steps can be superimposed onto horizontal swimlanes for the roles that perform the steps.
 
#*[[Workflow diagram]]. A graphical representation of activities and actions conducted by users of a system. (Sometimes called an activity diagram.)
 
#*[[Workflow diagram]]. A graphical representation of activities and actions conducted by users of a system. (Sometimes called an activity diagram.)
#'''[[Work breakdown structure]]''' (WBS). A deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project.
+
#'''[[Process model]]'''. A visual model or representation of the [[sequential flow]] and control logic of a set of related activities or actions.
#*[[Work package]].
 
#'''[[Process model]]'''. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.
 
 
#*[[Swimlane]]. The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role.
 
#*[[Swimlane]]. The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role.
 +
#*[[Network path]]. Any continuous series of connected activities in a project network diagram.
 +
#*[[Float]]. The amount of time that an activity may be delayed from its early start without delaying the project finish date. Float is a mathematical calculation, and can change as the project progresses and changes are made to the project plan. Also called [[slack time]], total float, and path float. See also free float.
 
#*[[Slack time]]. The amount of time an individual activity can be delayed without delaying the whole project.
 
#*[[Slack time]]. The amount of time an individual activity can be delayed without delaying the whole project.
 
#*[[Process map]]. A business model that shows a business process in terms of the steps and input and output flows across multiple functions, organizations, or job roles.
 
#*[[Process map]]. A business model that shows a business process in terms of the steps and input and output flows across multiple functions, organizations, or job roles.
#*[[Relationship map]]. A business model that shows the organizational context in terms of the relationships that exist among the organization, external customers, and providers.
+
#[[File:Dependency.png|400px|thumb|right|[[Logical relationship]]s]]'''[[Logical relationship]]'''. A dependency between two project activities, or between a project activity and a [[milestone]]. The four possible types of logical relationships exist.
#*[[Relationship]]. A defined association between concepts, classes or entities. Relationships are usually named and include the cardinality of the association.
+
#*[[Finish-to-start]] — the initiation of work of the successor depends upon the completion of work of the predecessor.
#*[[Entity-relationship diagram]]. An entity-relationship diagram is a graphical representation of the entities relevant to a chosen problem domain, the relationships between them, and their attributes.
+
#*[[Finish-to-finish]] — the completion of the work of the successor cannot finish until the completion of work of the predecessor.
 +
#*[[Start-to-start]] — the initiation of work of the successor depends upon the initiation of the work of the predecessor.
 +
#*[[Start-to-finish]] — the completion of the successor is dependent upon the initiation of the predecessor.
 +
#'''[[Network logic]]'''. The collection of activity dependencies that makes up a project network diagram.
 
#*[[Dependence]]. B's relationship to A when A possesses something that B requires.
 
#*[[Dependence]]. B's relationship to A when A possesses something that B requires.
#*[[Red route]]. The frequent and critical activities that users will perform on your site. They are complete activities, not single tasks, and will probably require several pages to execute. Defining the red routes for your site means that you’ll be able to identify and eliminate any usability obstacles on the key user journeys. (Important roads in London are known as ‘red routes’ and Transport for London do everything in their power to make sure passenger journeys on these routes are completed as smoothly and quickly as possible.)
+
#*[[Predecessor activity]]. The "from" activity.
#'''[[System]]'''. A set of interrelated and interdependent parts arranged in a manner that produces a unified whole.
+
#*[[Successor activity]]. The "to" activity.
#*[[System]]. A collection of interrelated elements that interact to achieve an objective. System elements can include hardware, software, and people. One system can be a sub-element (or subsystem) of another system.
+
#*[[Lag]]. A modification of a logical relationship that directs a delay in the successor task. For example, in a finish-to-start dependency with a ten-day lag, the successor activity cannot start until ten days after the predecessor has finished. See also lead.
#*[[System]]. A set of interrelated components working together to produce a desired result.
+
#*[[Lead]]. A modification of a logical relationship that allows an acceleration of the successor task. For example, in a finish-to-start dependency with a ten-day lead, the successor activity can start ten days before the predecessor has finished. See also lag.
 +
#'''[[Scheduling]]'''. (1) The process of planning and arranging orders to maximize productivity, cost, and delivery times; (2) Detailing what [[activity|activiti]]es have to be done, the order in which they are to be completed, who is to do each, and when they are to be completed.
 +
#*[[Timebox]]. (1) A fixed period of time to accomplish a desired outcome; (2) An assigned period of time during which an individual or team works toward an established goal. The team stops work when the time period concludes, rather than when work is completed. The team then assesses how much work was accomplished toward the specified goal.
 +
#*[[Timeboxing]]. Setting a duration for every activity and having it last exactly that (i.e. neither meetings nor sprint are ever lengthened - ever).
 +
#*[[Milestone]]. (1) A significant event in the project, usually completion of a deliverable or significant part of it; (2) A scheduled event to mark the completion of a major element of a product. Milestones are flags to signify that some amount of work has been completed.
 +
#*[[Visual scheduling]]. A real–time database of shop floor activity including new work, current work–in–progress, and completions. As work moves through the plant and operations are completed, the user receives instant feedback and is able to make adjustments to both the load (work orders) and the [[capacity]] to achieve a doable schedule.
 +
#'''[[Quality assurance]]''' (QA). (1) [[Enterprise effort]]s undertaken in order to evaluate overall performance within [[process]]es on a regular basis to provide confidence that the [[deliverable]]s will satisfy the requirement specifications, customer expectations, and relevant quality standards. In other words, [[quality assurance]] include the activities performed to ensure that a process will deliver products that meet an appropriate level of quality; (2) The [[organizational unit]] that is assigned responsibility for [[quality assurance]].
 +
#'''[[System]]'''. A collection of interrelated and/or interdependent elements working together as a unified whole to produce a desired [[output]] out of consumed [[input]] through one or more [[process]]es. System elements can include hardware, software, and people. One system can be a sub-element (or subsystem) of another system.
 
#*[[Mission]]. An undertaking that is supported by the system to be designed to be successful (e.g. space mission).
 
#*[[Mission]]. An undertaking that is supported by the system to be designed to be successful (e.g. space mission).
 
#*[[Open system]]. A [[system]] that interacts with its environment.
 
#*[[Open system]]. A [[system]] that interacts with its environment.
 
#*[[Closed system]]. A [[system]] that is not influenced by and does not interact with its environment.
 
#*[[Closed system]]. A [[system]] that is not influenced by and does not interact with its environment.
 
#*[[External interface]]. An interface with other systems (hardware, software, and human) that a proposed system will interact with.
 
#*[[External interface]]. An interface with other systems (hardware, software, and human) that a proposed system will interact with.
#*[[Boundary]]. A separation between the interior of a system and what lies outside.
+
#*[[System boundary]]. A separation between the interior of a [[system]] and what lies outside.
#*[[Context diagram]]. An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.
+
#*[[Ecosystem]] ([[system of systems]]).
#*#[[Context]]. The users, other systems and other features of the environment of the system that the system will interact with.
+
#'''[[System design]]'''. The identification of all the necessary components, their role, and how they have to interact for the system to fulfill its purpose.
 +
#*[[System integration]]. The activity of integrating all the components of a system to make sure they work together as intended.
 +
#*[[Interdisciplinarity]]. People from different disciplines working together to design systems.
 +
#*[[Specification]]. The technical requirements for [[system design]].
 +
#*[[Abstraction]]. The ability of [[engineer]]s to think of design concepts that are not dependent on specific solutions.
 +
#[[File:Ba-pm-se.png|400px|thumb|right|[[Business analysis]] vs [[project management]] vs [[systems engineering]]]]'''[[Systems engineering]]'''. The orderly process of bringing a system into being using a systems approach.
 +
#*[[Systems approach]]. The application of a systematic disciplined engineering approach that considers the system as a whole, its impact on its environment and continues throughout the lifecycle of a project.
 +
#*[[Ergonomics]]. The scientific discipline of studying interactions between humans and non-human systems, including [[human-computer interaction]] ([[human-computer interaction|HCI]]), in order to adapt work or working conditions to enhance performance of the worker. [[Ergonomics]] can be considered as a part of [[human factors]], which studies influence of human features on interactions with both non-human systems and human beings. When applied to design, the study of [[ergonomics]] seeks to optimize both human well-being and system performance.
 +
#*[[Datapoint-device architecture]].
 +
#*[[Object-oriented modeling]]. An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another. In some organizations, the same approach is used for business engineering to describe and package the logical components of the business.
 
#'''[[Business event]]'''. A system trigger that is initiated by humans.
 
#'''[[Business event]]'''. A system trigger that is initiated by humans.
 
#*[[Event]]. An event is something that occurs to which an organizational unit, system, or process must respond.
 
#*[[Event]]. An event is something that occurs to which an organizational unit, system, or process must respond.
 
#*[[Temporal event]]. A system trigger that is initiated by time.
 
#*[[Temporal event]]. A system trigger that is initiated by time.
 
#*[[Event response table]]. An analysis model in table format that defines the events (i.e., the input stimuli that trigger the system to carry out some function) and their responses.
 
#*[[Event response table]]. An analysis model in table format that defines the events (i.e., the input stimuli that trigger the system to carry out some function) and their responses.
#'''[[Feedback]]'''. Information about the output of a system that can be used to adjust it.
+
#'''[[Management process]]'''. A set of undefined or tentatively defined [[activity|activiti]]es performed for an [[enterprise]].
#*[[Output]]. What is produced by a system.
 
#*[[Desired outcome]]. The business benefits that will result from meeting the business need and the end state desired by stakeholders.
 
#'''[[Systems engineering]]'''. The orderly process of bringing a system into being using a systems approach.
 
#*[[Engineering]]. The application of scientific principles to practical ends.
 
#*[[Systems approach]]. The application of a systematic disciplined engineering approach that considers the system as a whole, its impact on its environment and continues throughout the lifecycle of a project.
 
#*[[System design]]. The identification of all the necessary components, their role, and how they have to interact for the system to fulfill its purpose.
 
#*[[System integration]]. The activity of integrating all the components of a system to make sure they work together as intended.
 
#*[[Human factor]]. Also called ergonomics. The scientific discipline of studying interactions between humans and external systems, including human-computer interaction. When applied to design, the study of human factors seeks to optimise both human well-being and system performance.
 
#*[[Interdisciplinarity]]. People from different disciplines working together to design systems.
 
#*[[Specifications]]. The technical requirements for systems design.
 
#*[[Datapoint-device architecture]].
 
#*[[Object-oriented modeling]]. An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another. In some organizations, the same approach is used for business engineering to describe and package the logical components of the business.
 
#'''[[Quality assurance]]''' (QA). The process of determining whether or not a product meets required specifications and customer expectations.
 
#*[[Quality]]. The degree to which a set of inherent characteristics fulfills requirements.
 
#*[[Quality assurance]] (QA). (1) The process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. (2) The organizational unit that is assigned responsibility for quality assurance.
 
#*[[Quality assurance]]. Activities performed to ensure that a process will deliver products that meet an appropriate level of quality.
 
  
 
===Roles===
 
===Roles===
 +
#'''[[Process owner]]'''. Someone authorized to change the [[process]].
 +
#'''[[System-user role]]'''. A set of capacities, often called permissions, that a [[system]] grants to any user who belongs to a particular role.
  
 
===Methods===
 
===Methods===
 
#'''[[Precedence diagramming method]]''' ([[Precedence diagramming method|PDM]]). A network diagramming technique in which activities are represented by boxes (or nodes). Activities are linked by precedence relationships to show the sequence in which the activities are to be performed.
 
#'''[[Precedence diagramming method]]''' ([[Precedence diagramming method|PDM]]). A network diagramming technique in which activities are represented by boxes (or nodes). Activities are linked by precedence relationships to show the sequence in which the activities are to be performed.
 +
#*[[Precedence relationship]]. The term used in the [[precedence diagramming method]] for a [[logical relationship]]. In current usage, however, precedence relationship, logical relationship, and dependency are widely used interchangeably, regardless of the diagramming method in use.
 
#'''[[Program Evaluation and Review Technique]]''' ([[Program Evaluation and Review Technique|PERT]]). An event-oriented network analysis technique used to estimate program duration when there is uncertainty in the individual activity duration estimates. PERT applies the critical path method using durations that are computed by a weighted average of optimistic, pessimistic, and most likely duration estimates. PERT computes the standard deviation of the completion date from those of the path's activity durations.
 
#'''[[Program Evaluation and Review Technique]]''' ([[Program Evaluation and Review Technique|PERT]]). An event-oriented network analysis technique used to estimate program duration when there is uncertainty in the individual activity duration estimates. PERT applies the critical path method using durations that are computed by a weighted average of optimistic, pessimistic, and most likely duration estimates. PERT computes the standard deviation of the completion date from those of the path's activity durations.
 
#*[[PERT network]]. A flowchart diagram showing the sequence of activities needed to complete a project and the time or cost associated with each.
 
#*[[PERT network]]. A flowchart diagram showing the sequence of activities needed to complete a project and the time or cost associated with each.
Line 85: Line 101:
 
#*[[Critical path]]. The longest sequence of activities in a [[PERT network]].
 
#*[[Critical path]]. The longest sequence of activities in a [[PERT network]].
 
#'''[[Critical path method]]''' ([[Critical path method|CPM]]). A network analysis technique used to predict project duration by analyzing which sequence of activities (which path) has the least amount of scheduling flexibility (the least amount of float). Early dates are calculated by means of a forward pass, using a specified start date. Late dates are calculated by means of a backward pass, starting from a specified completion date (usually the forward pass' calculated project early finish date).
 
#'''[[Critical path method]]''' ([[Critical path method|CPM]]). A network analysis technique used to predict project duration by analyzing which sequence of activities (which path) has the least amount of scheduling flexibility (the least amount of float). Early dates are calculated by means of a forward pass, using a specified start date. Late dates are calculated by means of a backward pass, starting from a specified completion date (usually the forward pass' calculated project early finish date).
 +
#*[[Critical path]]. The series of activities that determines the duration of the project. In a deterministic model, the critical path is usually defined as those activities with float less than or equal to a specified value, often zero. It is the longest path through the project. See critical path method.
 +
#*[[Critical activity]]. Any activity on a critical path. Most commonly determined by using the critical path method. Although some activities are "critical," in the dictionary sense, without being on the critical path, this meaning is seldom used in the project context.
 
#'''[[Six Sigma]]'''. A quality program designed to reduce defects and help lower costs, save time, and improve customer satisfaction.
 
#'''[[Six Sigma]]'''. A quality program designed to reduce defects and help lower costs, save time, and improve customer satisfaction.
#'''[[DevOps]]'''. Practice and a set of concepts, based on that practice, that define culture of unifying software development (Dev) and software operations (Ops). Its signature toolchain represents a chain of tools that fit one of the following categories: (a) Code, (b) Build, (c) Test, (d) Package, (e) Release, (f) Configure, and (e) Monitor.
 
 
#'''[[Process consultation]]'''. A meeting in which a consultant assists a client in understanding process events with which he or she must deal and identifying processes that need improvement.
 
#'''[[Process consultation]]'''. A meeting in which a consultant assists a client in understanding process events with which he or she must deal and identifying processes that need improvement.
 +
#'''[[Process principle]]'''. A basis of a [[process]].
 +
#*[[Don't repeat yourself]] (DRY). A [[process principle]] aimed at reducing repetition of process patterns, replacing them with abstractions; and several copies of the same data, using data normalization to avoid redundancy.
 +
#*[[Keep it simple, stupid]] (KISS). A [[process principle]] that most [[process]]es work better when they are kept as simple as possible.
  
 
===Instruments===
 
===Instruments===
#'''[[Flowchart software]]'''.  
+
#'''[[Flowchart software]]'''. A software implement used to create and modify [[flowchart]]s. Some graphics software can not just be used as [[flowchart software]], but may exceed some of its characteristics. For instance, [[Ikscape]] is able to create [[flowchart]]s using vector graphics, particularly the [[Scalable Vector Graphics]] (SVG) format, which produces graphics with higher quality in comparison with raster graphics.
#*[[LibreOffice Draw]].  
+
#*[[LibreOffice Draw]]. A vector graphics editor and diagramming tool. It provides connectors between shapes, which are available in a range of line styles and facilitate building drawings such as flowcharts. It also includes features similar to desktop publishing software and is able to act as a PDF-file editor.
#*[[Dia software]].  
+
#*[[Dia software]]. General-purpose diagramming software.
#*[[Inkscape]].
 
 
#'''[[Big visible chart]]'''. A large chart displayed near the Agile team that show how the team is progressing. You could make a big visible chart to show defects, velocity (burndown chart), customer acceptance tests, or to find out how much time the team is wasting.
 
#'''[[Big visible chart]]'''. A large chart displayed near the Agile team that show how the team is progressing. You could make a big visible chart to show defects, velocity (burndown chart), customer acceptance tests, or to find out how much time the team is wasting.
#*[[Burndown chart]] (or [[Release burndown chart|Burndown chart]]). The chart that represents all outstanding work. The vertical axis represents the backlog, while the horizontal axis represents time. The work remaining can be represented by story points, ideal days, team days, or other metrics.
+
#*[[Burndown chart]] (or [[Burndown chart|Release burndown chart]]). The chart that represents all outstanding work. The vertical axis represents the backlog, while the horizontal axis represents time. The work remaining can be represented by story points, ideal days, team days, or other metrics.
#*[[Burnup chart]] (or [[Release burnup chart|Burnup chart]]). The chart that tracks how much work has been completed. There are two lines on the chart—one line represents total work and the other represents work completed. The vertical axis represents the amount of work and can be measured in number of tasks, hours, or story points. The horizontal axis represents time, usually measured in days.
+
#*[[Burnup chart]] (or [[Burnup chart|Release burnup chart]]). The chart that tracks how much work has been completed. There are two lines on the chart—one line represents total work and the other represents work completed. The vertical axis represents the amount of work and can be measured in number of tasks, hours, or story points. The horizontal axis represents time, usually measured in days.
 +
#'''[[Work breakdown structure]]''' ([[Work breakdown structure|WBS]]). A deliverable-oriented hierarchical decomposition of the work to be executed within a [[project]] or [[operations]]. This ''structure'' organizes and defines the [[process scope]]. Each descending level represents an increasingly detailed definition of the work.
 +
#*[[Responsibility assignment matrix]] (RAM). A structure that relates the [[organization structure]] to the [[work breakdown structure]] to help ensure that each element of the work is assigned to a responsible individual.
 +
#*[[Resource leveling]]. Any form of network analysis in which scheduling decisions (start and finish dates) are driven by resource management concerns (e.g., limited resource availability or difficult-to-manage changes in resource levels).
 +
#'''[[Context diagram]]'''. An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.
 +
#*[[Context]]. The users, other systems and other features of the environment of the system that the system will interact with.
 +
#'''[[Strategic development tripod]]'''.
 +
#*[[Tailorable process]] that guides development.
 +
#*[[Process tool]] that automates the application of that process.
 +
#*[[Process service]] that accelerates adoption of both the process and the tools.
 +
#'''[[Linear programming]]'''. A mathematical technique that solves resource allocation problems.
 +
 
 +
===Results===
 +
#'''[[Effort portfolio]]'''. The collection of [[enterprise effort]]s undertaken by one [[enterprise]]. At the highest level, an [[effort portfolio]] is the collection of [[project]]s and [[operations]], which can be further broken down to [[process]]es, [[activity|activiti]]es, and, at the lowest level, down to [[job task]]s.
 +
#'''[[Performance measurement baseline]]''' (sometimes, [[baseline]] or [[requirement baseline]]). A point-in-time view of requirements that have been reviewed and agreed upon (i.e., "approved") to serve as a basis for further development and possible changes. In other words, the ''baseline'' is any originally-approved plan adjusted by approved changes. Usually, the term ''baseline'' is used with a modifier such as [[product baseline]], [[process baseline]], [[project cost baseline]], and [[project schedule baseline]].
  
 
===Practices===
 
===Practices===
  
''The successor lecture is [[Operations Management Quarter]].''
+
''[[Operations Management Quarter]] is the successor lecture. In the [[enterprise envisioning]] series, the next lecture is [[Individual Decisions Quarter]].''
  
 
==Materials==
 
==Materials==
Line 110: Line 143:
  
 
==See also==
 
==See also==
 +
 +
[[Category:Septem Artes Administrativi]][[Category:Lecture notes]]

Latest revision as of 04:47, 6 January 2023

Effort Engineering Quarter (hereinafter, the Quarter) is a lecture introducing the learners to operations design primarily through key topics related to effort engineering. The Quarter is the third of four lectures of Operations Quadrivium, which is the third of seven modules of Septem Artes Administrativi (hereinafter, the Course). The Course is designed to introduce the learners to general concepts in business administration, management, and organizational behavior.


Outline

Controlling Quarter is the predecessor lecture. In the enterprise envisioning series, the previous lecture is Business Modeling Quarter.

Concepts

  1. Effort engineering. The creative application of science, mathematical methods, and empirical evidence to the innovation, design, construction, operation and maintenance of processes.
  2. Process. A sequenced series, predefined, empiric, and/or merely chaotic, of activities undertaken in order to achieve particular results. In other words, a process is a repetitive or ad-hoc way of work. Effort engineering defines that those activities convert inputs into desired outputs utilizing some process assets such as tools and techniques and while being influenced by some enterprise factors. Non-repetitive processes are called management processes. Repetitive processes that are performed by people for enterprises are called business processes; those of their sets that produce a deliverable are called operations. Repetitive processes that are performed by systems including computers, robots, and/or machines are called system processes.
  3. Output. Anything that directly emerges out of a process. In systems engineering, items that the system produces.
    • Deliverable. Anything that one party has agreed to deliver to another party. A deliverable is a tangible and/or intangible output that is produced by a project or operations and ready to be shipped to the beneficiaries. Usually, a deliverable consists of an unpackaged deliverable and packaging.
    • Feedback. (1) Data that is an output from one system delivered back to one of the systems that feed the system that produces the data; (2) Information based on data that is an output from one system delivered back to one of this system's suppliers; (3) The degree to which carrying out the work activities required by a job results in the individual's obtaining direct and clear information about the effectiveness of his or her performance.
  4. Outcome. A key factor that is affected by some other variables.
    • Desired outcome. The business benefits that will result from meeting the business need and the end state desired by stakeholders.
  5. Process property. An attribute, quality, or characteristic of a process.
  6. Business process. A set of defined collaborative activities performed in a repeatable fashion by an enterprise. Processes are triggered by events and may have multiple possible outcomes. A successful outcome of a process is going to deliver value to one or more stakeholders.
    • Production process.
    • Cycle. Refers to the total amount of time it takes for a single task or work item to travel through the workflow from the beginning of work until it ships.
  7. Production. The action of making or manufacturing from components or raw materials, or the process of being so manufactured.
    • Process production. The production of items in continuous process.
    • Unit production. The production of items in units or small batches.
    • Production environment. A term describing the setting where a product is put into use by customers on a regular basis.
    • Operational support. A stakeholder who helps to keep the solution functioning, either by providing support to end users (trainers, help desk) or by keeping the solution operational on a day-to-day basis (network and other tech support).
  8. Activity. Any enterprise effort performed as part of a process. An activity shall have its own name and description; most often, they have one or more predecessor activities and successor activities. Planned activities may have their expected input resources, process assets, time frames, and costs; completed activities may have their actual data. Activities may be subdivided into job tasks.
    • Activity diagram. A model that illustrates the flow of processes and/or complex use cases by showing each activity along with information flows and concurrent activities. Steps can be superimposed onto horizontal swimlanes for the roles that perform the steps.
    • Workflow diagram. A graphical representation of activities and actions conducted by users of a system. (Sometimes called an activity diagram.)
  9. Process model. A visual model or representation of the sequential flow and control logic of a set of related activities or actions.
    • Swimlane. The horizontal or vertical section of a process model that show which activities are performed by a particular actor or role.
    • Network path. Any continuous series of connected activities in a project network diagram.
    • Float. The amount of time that an activity may be delayed from its early start without delaying the project finish date. Float is a mathematical calculation, and can change as the project progresses and changes are made to the project plan. Also called slack time, total float, and path float. See also free float.
    • Slack time. The amount of time an individual activity can be delayed without delaying the whole project.
    • Process map. A business model that shows a business process in terms of the steps and input and output flows across multiple functions, organizations, or job roles.
  10. Logical relationship. A dependency between two project activities, or between a project activity and a milestone. The four possible types of logical relationships exist.
    • Finish-to-start — the initiation of work of the successor depends upon the completion of work of the predecessor.
    • Finish-to-finish — the completion of the work of the successor cannot finish until the completion of work of the predecessor.
    • Start-to-start — the initiation of work of the successor depends upon the initiation of the work of the predecessor.
    • Start-to-finish — the completion of the successor is dependent upon the initiation of the predecessor.
  11. Network logic. The collection of activity dependencies that makes up a project network diagram.
    • Dependence. B's relationship to A when A possesses something that B requires.
    • Predecessor activity. The "from" activity.
    • Successor activity. The "to" activity.
    • Lag. A modification of a logical relationship that directs a delay in the successor task. For example, in a finish-to-start dependency with a ten-day lag, the successor activity cannot start until ten days after the predecessor has finished. See also lead.
    • Lead. A modification of a logical relationship that allows an acceleration of the successor task. For example, in a finish-to-start dependency with a ten-day lead, the successor activity can start ten days before the predecessor has finished. See also lag.
  12. Scheduling. (1) The process of planning and arranging orders to maximize productivity, cost, and delivery times; (2) Detailing what activities have to be done, the order in which they are to be completed, who is to do each, and when they are to be completed.
    • Timebox. (1) A fixed period of time to accomplish a desired outcome; (2) An assigned period of time during which an individual or team works toward an established goal. The team stops work when the time period concludes, rather than when work is completed. The team then assesses how much work was accomplished toward the specified goal.
    • Timeboxing. Setting a duration for every activity and having it last exactly that (i.e. neither meetings nor sprint are ever lengthened - ever).
    • Milestone. (1) A significant event in the project, usually completion of a deliverable or significant part of it; (2) A scheduled event to mark the completion of a major element of a product. Milestones are flags to signify that some amount of work has been completed.
    • Visual scheduling. A real–time database of shop floor activity including new work, current work–in–progress, and completions. As work moves through the plant and operations are completed, the user receives instant feedback and is able to make adjustments to both the load (work orders) and the capacity to achieve a doable schedule.
  13. Quality assurance (QA). (1) Enterprise efforts undertaken in order to evaluate overall performance within processes on a regular basis to provide confidence that the deliverables will satisfy the requirement specifications, customer expectations, and relevant quality standards. In other words, quality assurance include the activities performed to ensure that a process will deliver products that meet an appropriate level of quality; (2) The organizational unit that is assigned responsibility for quality assurance.
  14. System. A collection of interrelated and/or interdependent elements working together as a unified whole to produce a desired output out of consumed input through one or more processes. System elements can include hardware, software, and people. One system can be a sub-element (or subsystem) of another system.
  15. System design. The identification of all the necessary components, their role, and how they have to interact for the system to fulfill its purpose.
  16. Systems engineering. The orderly process of bringing a system into being using a systems approach.
    • Systems approach. The application of a systematic disciplined engineering approach that considers the system as a whole, its impact on its environment and continues throughout the lifecycle of a project.
    • Ergonomics. The scientific discipline of studying interactions between humans and non-human systems, including human-computer interaction (HCI), in order to adapt work or working conditions to enhance performance of the worker. Ergonomics can be considered as a part of human factors, which studies influence of human features on interactions with both non-human systems and human beings. When applied to design, the study of ergonomics seeks to optimize both human well-being and system performance.
    • Datapoint-device architecture.
    • Object-oriented modeling. An approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another. In some organizations, the same approach is used for business engineering to describe and package the logical components of the business.
  17. Business event. A system trigger that is initiated by humans.
    • Event. An event is something that occurs to which an organizational unit, system, or process must respond.
    • Temporal event. A system trigger that is initiated by time.
    • Event response table. An analysis model in table format that defines the events (i.e., the input stimuli that trigger the system to carry out some function) and their responses.
  18. Management process. A set of undefined or tentatively defined activities performed for an enterprise.

Roles

  1. Process owner. Someone authorized to change the process.
  2. System-user role. A set of capacities, often called permissions, that a system grants to any user who belongs to a particular role.

Methods

  1. Precedence diagramming method (PDM). A network diagramming technique in which activities are represented by boxes (or nodes). Activities are linked by precedence relationships to show the sequence in which the activities are to be performed.
  2. Program Evaluation and Review Technique (PERT). An event-oriented network analysis technique used to estimate program duration when there is uncertainty in the individual activity duration estimates. PERT applies the critical path method using durations that are computed by a weighted average of optimistic, pessimistic, and most likely duration estimates. PERT computes the standard deviation of the completion date from those of the path's activity durations.
  3. Critical path method (CPM). A network analysis technique used to predict project duration by analyzing which sequence of activities (which path) has the least amount of scheduling flexibility (the least amount of float). Early dates are calculated by means of a forward pass, using a specified start date. Late dates are calculated by means of a backward pass, starting from a specified completion date (usually the forward pass' calculated project early finish date).
    • Critical path. The series of activities that determines the duration of the project. In a deterministic model, the critical path is usually defined as those activities with float less than or equal to a specified value, often zero. It is the longest path through the project. See critical path method.
    • Critical activity. Any activity on a critical path. Most commonly determined by using the critical path method. Although some activities are "critical," in the dictionary sense, without being on the critical path, this meaning is seldom used in the project context.
  4. Six Sigma. A quality program designed to reduce defects and help lower costs, save time, and improve customer satisfaction.
  5. Process consultation. A meeting in which a consultant assists a client in understanding process events with which he or she must deal and identifying processes that need improvement.
  6. Process principle. A basis of a process.

Instruments

  1. Flowchart software. A software implement used to create and modify flowcharts. Some graphics software can not just be used as flowchart software, but may exceed some of its characteristics. For instance, Ikscape is able to create flowcharts using vector graphics, particularly the Scalable Vector Graphics (SVG) format, which produces graphics with higher quality in comparison with raster graphics.
    • LibreOffice Draw. A vector graphics editor and diagramming tool. It provides connectors between shapes, which are available in a range of line styles and facilitate building drawings such as flowcharts. It also includes features similar to desktop publishing software and is able to act as a PDF-file editor.
    • Dia software. General-purpose diagramming software.
  2. Big visible chart. A large chart displayed near the Agile team that show how the team is progressing. You could make a big visible chart to show defects, velocity (burndown chart), customer acceptance tests, or to find out how much time the team is wasting.
    • Burndown chart (or Release burndown chart). The chart that represents all outstanding work. The vertical axis represents the backlog, while the horizontal axis represents time. The work remaining can be represented by story points, ideal days, team days, or other metrics.
    • Burnup chart (or Release burnup chart). The chart that tracks how much work has been completed. There are two lines on the chart—one line represents total work and the other represents work completed. The vertical axis represents the amount of work and can be measured in number of tasks, hours, or story points. The horizontal axis represents time, usually measured in days.
  3. Work breakdown structure (WBS). A deliverable-oriented hierarchical decomposition of the work to be executed within a project or operations. This structure organizes and defines the process scope. Each descending level represents an increasingly detailed definition of the work.
  4. Context diagram. An analysis model that illustrates product scope by showing the system in its environment with the external entities (people and systems) that give to and receive from the system.
    • Context. The users, other systems and other features of the environment of the system that the system will interact with.
  5. Strategic development tripod.
  6. Linear programming. A mathematical technique that solves resource allocation problems.

Results

  1. Effort portfolio. The collection of enterprise efforts undertaken by one enterprise. At the highest level, an effort portfolio is the collection of projects and operations, which can be further broken down to processes, activities, and, at the lowest level, down to job tasks.
  2. Performance measurement baseline (sometimes, baseline or requirement baseline). A point-in-time view of requirements that have been reviewed and agreed upon (i.e., "approved") to serve as a basis for further development and possible changes. In other words, the baseline is any originally-approved plan adjusted by approved changes. Usually, the term baseline is used with a modifier such as product baseline, process baseline, project cost baseline, and project schedule baseline.

Practices

Operations Management Quarter is the successor lecture. In the enterprise envisioning series, the next lecture is Individual Decisions Quarter.

Materials

Recorded audio

Recorded video

Live sessions

Texts and graphics

See also